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EXECUTIVE  SUMMARY 


This  report  documents  work  that  Stanford  Research  Institute  (SRI) 
has  performed  for  the  Office  of  Aviation  Policy,  Federal  Aviation  Adminis- 
tration (FAA) , Department  of  Transportation,  to  assess  the  impact  that 
certain  proposed  Upgraded  Third  Generation  (UG3RD)  Terminal  Air  Traffic 
Control  (ATC)  System  alternatives  would  have  upon  terminal  ATC  operations 
at  the  Oakland  Bay  and  Los  Angeles  Terminal  Radar  Approach  Control  (TRACON) 
facilities.  To  compare  the  operational  effects  of  the  alternative  UG3RD, 
we  estimate  controller  manning  requirements  associated  with  each  alterna- 
tive system,  based  on  models  of  controller  workload  and  on  traffic  fore- 
casts provided  by  the  FAA.  The  basic  modeling  formulation  was  developed 
in  previous  contract  work  addressing  enroute  ATC  operations  for  the 
Office  of  Aviation  Policy  and  the  Systems  Research  and  Development  Ser- 
vice, FAA;  this  modeling  scheme  has  been  adjusted  to  represent  terminal 
ATC  operations,  based  on  field  observations  made  at  the  two  TRACON  study 
sites. 


Method  of  Approach 

We  collected  data  at  the  Oakland  Bay  TRACON  and  the  Los  Angeles 
TRACON  describing  the  task  activities  of  the  terminal  sector  control  team 
which  are  required  under  the  current  Automated  Radar  Terminal  System  (ARTS) 
III  operation.  Data  was  collected  from  the  six  sectors  (out  of  ten)  at 
the  Oakland  Bay  TRACON  which  handle  arrival  and  departure  traffic  for 
San  Francisco  International  Airport  and  from  all  four  sectors  (supported 
by  two  parallel  monitoring  positions)  of  the  Los  Angeles  TRACON,  which 
serves  the  Los  Angeles  International  Airport.  However,  operations  at 
each  airport's  Airport  Traffic  Control  Tower,  which  are  not  collocated 
with  the  TRACONs,  are  not  addressed  in  this  report.  Both  TRACONs  are 
designated  as  Group  I Terminal  Control  Area  (TCA)  facilities. 

For  each  sector,  the  data  were  used  to  construct  workload  models 
describing  the  sector  team  routine,  surveillance,  and  conflict  process- 
ing requirements  observed  at  each  TRACON.  Routine  work  includes  air/ 
ground  (A/G)  voice  communications,  manual  computer  data  entry  or  display 
operations,  paper  flight  strip  and  scratch-pad  data  processing,  inter- 
sector interphone  voice  communications,  and  face-to-face  communications. 
Surveillance  work  Involves  the  visual  observation  of  radar-derived  air- 
craft situation  data  on  a plan  view  display  (PVD) . Conflict  processing 
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work  includes  potential  conflict  recognition,  assessment,  and  resolution 
decision  making  and  it  involves  A/G  voice  communications.  The  models  were 
used  to  quantify  the  relationship  between  workload  limits  and  traffic 
capacity  for  the  selected  sectors  of  the  two  TRACONs.  Workload-capacity 
relationships  were  developed  for  various  sector  manning  regimes  under 
both  visual  and  instrument  approach  operations.  These  workload  models 
and  capacity  relationships  describe  the  operational  characteristics  of 
the  current  ARTS  III  terminal  ATC  system,  which  is  the  base  from  which 
we  have  postulated  the  evolution  of  the  UG3RD  systems. 

To  analyze  ATC  evolution  through  successive  automation  levels,  we 
adjusted  parameters  of  the  workload  models  to  represent  the  effects  of 
various  UG3RD  systems  on  the  sector  teams'  capability  for  traffic  handling. 
The  parametric  values  encode  assumptions  we  have  made  as  to  how  each  sys- 
tem would  be  implemented  in  an  operational  terminal  environment,  and  how 
each  system  would  affect  the  task  activities  and  workload  characteristics 
of  individual  sector  teams.  The  modeling  approach,  which  we  call  the 
Relative  Capacity  Estimating  Process  (RECEP) , estimates  the  sector  traffic 
capacity  associated  with  an  UG3RD  system  relative  to  the  performance  re- 
quirements of  current  ATC  operations. 

The  capacities  estimated  for  individual  sectors  were  used  to  deter- 
mine multisector  manning  requirements  for  increments  in  day-shift  traffic 
projections.  Peak-hour  manning  requirements  for  each  sector  were  deter- 
mined by  matching  sector  capacities  against  traffic  projections  and  esti- 
mating the  resectorization  and  sector  manning  increases  needed  to  handle 
the  increments  in  traffic.  We  have  not  attempted  to  estimate  delay 
effects  because  such  effects  would  largely  be  determined  by  airport  con- 
straints, rather  than  constraints  upon  TRACON  controllers.  The  individual 
sector  manning  requirements  (for  each  sector's  peak  hour  in  the  day  shift) 
were  combined  to  estimate  multisector  day-shift  manning,  which  includes 
the  number  of  sector  radar  and  handoff  positions — controllers,  coordina- 
tors, parallel  monitors,  and  flight  data--needed  to  handle  the  projected 
traffic.  This  estimate  does  not  include  staffing  allowances  for  adminis- 
tration, relief,  annual  and  sick  leave,  excess  shift  capacity,  training, 
or  special  assignments.  For  each  sector,  we  used  the  1975  statistics  on 
busy  day  (90th  percentile)  eight-hour  traffic  as  the  base  for  projections. 
This  procedure  was  applied  to  the  current  ARTS  III  and  UG3R0  systems  to 
enable  comparison  of  manning  requirements  at  selected  traffic  levels. 

Sector  traffic  capacities  for  the  UG3RD  systems  were  derived  using 
the  workload  models,  from  which  we  determined  multisector  manning  require- 
ments. Therefore,  the  resulting  manning  estimates  are  sensitive  to  the 
subjective  judgments  we  have  made  in  structuring  the  workload  models  so 
that  they  describe  an  evolutionary  implementation  of  UG3RD  features.  In 


S-2 


the  remainder  of  this  Executive  Summary,  we  briefly  review  the  opera- 
tional assumptions  and  present  the  manning  estimates. 


Assumptions 

The  systems  are  examined  in  sequence  under  the  assumption  that  each 
UG3RD  feature  is  added  to  the  previous  system.  The  UG3RD  features,  added 
consecutively  to  the  ARTS  III  Base  (System  1),  are: 

• Automated  data  handling  (System  2) 

• Basic  metering  and  spacing  (System  3) 

• Sector  conflict  probe  (System  4) 

• Area  navigation  (RNAV)  (System  5) 

• Discrete  Address  Beacon  System  (DABS)  data  link  (System  6) 

• DABS-based  intermittent  positive  control  (IPG). 


Automated  Data  Handling  (System  2) --This  first  add-on  to  System  1 
includes  the  implementation  of  an  electronic  tabular  flight  data  display 
at  sector  positions.  The  tabular  display  is  an  electronic  presentation 
of  flight  data,  designated  to  replace  paper  flight  strips  and  attendant 
manual  activities.  It  would  effectively  automate  some  of  the  controller's 
manual  and  verbal  tasks  associated  with  control  procedures  and  flight  data 
distribution. 


Basic  Metering  and  Spacing  (System  3) — This  feature,  which  we  assume 
is  added  on  to  System  2,  is  a terminal  ATC  device  to  maximize  airport 
runway  use  through  precise  control  of  interarrival  times  at  runway  thresh- 
olds. Suggested  control  instructions  regarding  aircraft  headings,  speeds, 
and  altitude  would  be  issued  to  TRACON  controllers  by  the  computerized 
metering  and  sequencing  operation.  Some  workload  reductions  would  be 
realized  because  this  system  would  reduce  the  decision  time  a controller 
needs  to  assess  and  determine  aircraft  sequence  assignment  and  to  detect 
potential  conflicts  along  inbound  flight  paths.  We  do  not  envision  a 
significant  impact  on  minute-by-minute  control  activities, 

A refined  metering  and  spacing  system  would  extend  the  basic  service 
by  including  departures  and  multiple  airports  in  complex  terminal  areas. 

A refined  system  would  not  fundamentally  change  the  basic  metering  and 
spacing  operations,  and  we  have  not  explicitly  modeled  such  a refinement. 
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Sector  Conflict  Probe  (System  4) --This  feature,  which  we  assume  is 
added  on  to  System  3,  alerts  controllers  to  potential  conflicts  and  recom- 
mends resolution  actions.  To  provide  an  operationally  realistic  time 
prediction  horizon  with  a low  false-alarm  rate,  we  assume  this  feature 
will  be  used  when  aircraft  first  enter  a sector.  Since  A/G  communications 
are  required  to  transmit  conflict  resolution  instructions,  workload  reduc- 
tions affect  only  conflict  detection  and  assessment  tasks. 


RNAV  (System  5) --This  feature,  which  we  assume  is  added  on  to  Sys- 
tem 4,  incorporates  navigation  avionics  to  achieve  close-spaced  multi-lane 
traffic  routes.  Processing  of  overtaking  conflicts  in  departure  sectors 
would  be  eliminated  by  placing  successive  aircraft  on  closely  spaced  paral- 
lel routes. 


DABS  Data  Link  (System  6) --This  feature,  which  we  assume  is  added  on 
to  System  5,  transmits  digital  data  to  pilots,  including  routine  clear- 
ances and  conflict  avoidance  directives.  It  is  not  intended  to  transmit 
extensive  nonstandard- format  messages.  The  data  link,  integrated  with 
extensive  computerization,  is  the  basis  for  the  "control-by-exception" 
concept  in  which  the  controller  would  become  a system  manager  who  is  not 
routinely  engaged  in  making  minute-by-minute  tactical  decisions.  He  would 
have  to  monitor  the  computerized  sector  control  operation  and  intervene 
when  necessary  to  adjust  procedural  rules,  respond  to  pilot  requests,  or 
resolve  nonstandard  situations.  We  note  that  the  advanced  metering  and 
spacing  feature  functions  with  the  data  link,  and  this  feature  is  Included 
in  terminal  ATC  control-by-exception  operations.  In  modeling  the  workload 
changes  associated  with  this  system,  we  have  accounted  for  the  automation 
of  certain  routine  and  conflict  tasks  while  allowing  for  the  controller 
work  required  to  maintain  operational  cognizance. 


DABS  IPC--IPC  provides  traffic  advisories  and  threat  avoidance  com- 
mands to  pilots,  as  needed.  Since  this  service  could  operate  in  the  posi- 
tive control  environment  on  imminent  conflict  situations  that  might  be 
missed  by  controllers,  we  have  assumed  IPC  to  be  a safety  enhancement 
device  which  would  not  directly  affect  routine  staffing  requirements. 

IPC  may  be  necessary  to  provide  fault  tolerance  in  the  event  of  failure 
in  the  operation  of  the  other  UG3RD  enhancement  systems.  However,  we 
have  not  explicitly  modeled  DABS  IPC. 
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Results 


Projecting  25  percent  increments  in  traffic,  we  have  determined 
busy-day,  day-shift  controller  manning  requirements  for  the  six  Oakland 
Bay  TRACON  sectors  and  the  four  Los  Angeles  TRACON  sectors.  Results  of 
these  analyses  for  the  ATC  system  alternatives  are  partly  summarized  in 
Table  S-1.  The  factors  shown  in  this  table  measure  the  growth  estimates 
for  traffic  and  manning  relative  to  the  1975  busy  day. 

According  to  Table  S-1,  manning  requirements  increase  as  the  traffic 
approaches  twice  the  1975  level  and  gradually  level  off  as  traffic  in- 
creases beyond  this  2.0  factor  (or  thereafter,  depending  on  the  alterna- 
tive UG3RD  system) . In  developing  these  manning  requirements,  we  recog- 
nized that  the  Oakland  Bay  and  Los  Angeles  TRACONs  currently  have  a 
well -developed  sectorization  structure,  and  major  increases  in  the  num- 
ber of  control  sectors  are  not  expected.  Therefore,  the  manning  increases 
shown  in  Table  S-1  are  largely  due  to  within-sector  manning  adjustments 
(e.g. , one-man  versus  two-man  sectors),  with  some  allowances  for  minor 
sectorization  adjustments.  This  limit  on  the  number  of  sectors  and 
logical  limits  on  sector  team  size  cause  our  manning  projections  to 
level  off. 

Because  of  the  manning  limitations,  we  expect  workload  saturation 
to  occur  if  traffic  increases  significantly  beyond  the  2.0  factor.  If 
such  an  increase  occurs,  traffic  disruptions  would  cause  significant 
change  to  the  operational  assumptions  we  have  made  in  modeling  sector 
capacity  and  manning.  Therefore,  as  far  as  the  manning  factor  estimates 
in  Table  S-1  are  concerned,  comparisons  between  systems  should  be  made 
only  for  those  traffic  factors  at  or  below  2.0.  But  in  any  case,  manning 
comparisons  at  higher  traffic  levels  should  not  be  relevant  to  the 
Oakland  Bay  and  Los  Angeles  TRACON  sectors  since  traffic  forecasts  for 
their  primary  airports  do  not  approach  the  2.0  level  by  the  year  2000. 

Figure  S-1  contains  a composite  graphical  representation  of  the 
relationships  found  in  Table  S-1  between  traffic  and  day-shift  manning 
requirements  for  traffic  factors  at  or  below  2.0.  The  graphical  repre- 
sentations were  structured  by  fitting  curves  to  the  paired  data  given 
in  Table  S-1  for  both  TRACONs.  Figure  S-1  enables  comparison  of  the 
overall  manning  trends  associated  with  each  ATC  system  alternative;  these 
graphs  do  not  describe  manning  relationships  developed  for  a specific 
TRACON. 
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TRAFFIC  FACTOR  — 1975  BASE 

SA-4416-23 

FIGURE  S-1  TRACON  CONTROLLER  MANNING  TREND 


Observations 


To  provide  some  insight  into  the  relative  efficiencies  of  the  sys- 
tems, we  examine  the  productivity  trends  of  Figure  S-1  at  the  current 
traffic  factor  (1.0)  and  then  double  this  traffic  level.  As  shown  in 
Table  S-2,  a productivity  factor  is  determined  and  used  to  measure  the 
traffic  handling  capabilities  of  each  system's  control  personnel,  rela- 
tive to  the  current  ARTS  III  base  (System  1).  At  the  1.0  traffic  factor. 
System  2 (automated  data  handling)  shows  a 25  percent  productivity  gain 
relative  to  System  1,  while  System  6 (DABS  data  link)  shows  an  85  per- 
cent productivity  gain  over  System  1;  the  intermediate  systems  show  no 
productivity  gains  beyond  those  achieved  by  System  2.  At  the  2.0  traffic 
factor.  System  2 shows  a 14  percent  productivity  gain,  and  System  6 shows 
one  of  87  percent;  the  intermediate  systems  show  incremental  gains  of 
lower  magnitude. 
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Table  S-2 
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We  see  that  Systems  2 and  6 are  shown  to  have  the  most  significant 
impact  on  manning  requirements,  while  Systems  3,  4,  and  5 have  limited 
effect.  However,  through  evolutionary  development  the  latter  systems 
are  assumed  to  be  integrated  into  System  6,  and  their  operation  would  be 
required  to  achieve  the  productivity  gain  of  System  6, 


Remarks 


Manning  estimates  were  made  using  controller  workload  models.  These 
models  are  reasonably  logical  representations  of  ATC  systems  operation, 
but,  being  analytical  in  nature,  they  are  merely  abstractions  from  the 
real  world.  Therefore,  the  resulting  staffing  estimates  should  only  be 
interpreted  as  first-order  predictions  of  the  relative  effect  of  the 
various  UG3RD  automation  features.  These  estimates  should  be  useful 
guidelines  for  further  experimental  testing  of  the  various  systems  in 
order  to  define  their  operational  and  technological  design  feasibility, 
and  for  developing  detailed  economic  feasibility  analyses. 

Relative  to  operational  and  technological  feasibility,  we  emphasize 
that  many  of  our  modeling  assumptions  are  based  on  judgments  concerning 
the  implementation  capabilities  of  the  enhancement  features.  We  assume, 
for  example,  that  a conflict  probe  could  indeed  be  used  to  predict  and 
resolve  conflicts  within  an  air  space  sector;  however,  there  is  the  ques- 
tion of  whether  a conflict  probe  of  any  type  could  be  integrated  with  a 
controller's  human  cognitive  capabilities.  In  fact,  the  basic  issue  of 
productively  interfacing  man  and  machine  applies  to  each  feature  and 
requires  considerable  additional  study,  experimentation,  and  evaluation. 
This  is  especially  true  of  the  data-link-based  control-by-exception 
operation  in  which  the  cognitive  processes  of  the  controller  must  be 
evolved  into  a system-interactive  monitoring  mode.  Moreover,  further 
research  is  needed  to  ascertain  the  degree  to  which  a controller's  cog- 
nitive capacity  would  constrain  his  ability  to  handle  more  traffic. 

In  regard  to  economic  feasibility,  our  manning  estimates  provide 
insights  into  the  relative  effectiveness  of  each  system  in  reducing  FAA 
operating  costs  for  manpower.  Howevever,  a full  economic  analysis  would 
have  to  consider  trade-offs  between  FAA  costs  for  operations,  engineering 
and  development,  and  capital  investment  and  user  costs  of  delay  and 
avionics.  Furthermore,  since  the  scope  of  this  effort  is  restricted  to 
estimating  TRACON  manning  requirements,  the  various  UG3RD  systems  are 
not  assessed  relative  to  safety,  airport  capacity,  and  other  effects. 
Systems  that  do  not  have  a significant  effect  upon  TRACON  manning,  such 
as  IPC  or  Wake  Vortex  Avoidance,  should  not  be  dismissed  lightly;  such 
features  may  contribute  important  qualities  other  than  ..educed  terminal 
manpower  needs. 
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I INTRODUCTION 


A.  Obiectives  and  Scope 

The  work  described  here  assesses  the  effect  on  terminal  air  traffic 
control  (ATC)  operations  of  various  automation  systems  proposed  as  part 
of  the  Upgraded  Third  Generation  (UG3RD)  Terminal  ATC  program.  The 
alternative  UG3RD  systems  are  examined  in  the  light  of  currently  observed 
control  operations  in  order  to  judge  how  these  automated  advances  might 
successfully  be  integrated  with  operational  requirements  and  how  control- 
ler activities  might  change.  We  evaluate  the  operational  potentials  of 
the  various  UG3RD  alternatives  by  estimating  and  comparing  their  effects 
on  manpower  needs  at  two  terminal  facilities,  the  Oakland  Bay  and  the  Los 
Angeles  Terminal  Radar  Approach  Control  (TRACON)  facilities.  The  cur- 
rently used  Automated  Radar  Terminal  System  (ARTS)  III  was  selected  as 
a basis  for  comparing  the  manning  requirements. 

This  study  was  performed  for  the  Office  of  Aviation  Policy,  Federal 
Aviation  Administration  (FAA) , under  Contract  DOT-FA75WA-3714. 


B.  Background 

This  work  is  based  on  ATC  analysis  capabilities  developed  by  SRI 
during  projects  previously  conducted  for  the  FAA.  The  first  project 
was  a multiyear  effort  performed  for  the  Systems  Research  and  Development 
Service,  FAA,  during  which  we  studied  enroute  ATC  operations,  developed 
various  analytical  models  of  ATC  operations,  and  studied  the  operational 
realities  of  automation  and  its  potential  for  implementation.  The  models 
included  the  Relative  Capacity  Estimating  Process  (RECEP) , which  relates 
controller  workload  requirements  to  sector  traffic  capacities,  and  the 
Air  Traffic  Flow  (ATF)  network  simulation  model,  which  assesses  traffic 
capacity  and  delay  in  a multisector  enroute  environment. 


* 

A list  of  references  is  appended  to  this  report. 
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The  second  project^  was  a case  study  of  UG3RD  ATC  operational  impact 
for  the  Los  Angeles  Center,  which  we  performed  for  the  Office  of  Aviation 
Policy,  FAA.  We  used  the  RECEP  and  ATF  models  to  estimate  staffing  needs 
under  the  various  automation  systems.  A similar  case  study  was  performed 
for  the  Atlanta  Center  as  part  of  the  current  overall  contract  effort, 
but  it  is  documented®  separately  from  this  report. 

The  studies  in  this  report  of  UG3RD  operational  impact  at  the  Oakland 
Bay  and  Los  Angeles  TRACONs  parallel  those  of  the  two  initial  centers. 
However,  the  TRACON  case  studies  are  based  on  applications  of  the  RECEP 
model  and  do  not  use  the  ATF  model  (since  we  assume  terminal  area  delays 
are  largely  determined  by  airport  constraints  rather  than  terminal  con- 
troller limitations).  In  using  RECEP  to  model  UG3RD  ATC  system  alterna- 
tives, we  made  a number  of  assumptions  and  judgments  regarding  the  feasi- 
bility of  implementing  these  alternatives  in  an  operational  environment. 
Our  models  of  controller  workload  encoded  such  assumptions  regarding 
possible  system  implementation.  In  some  cases,  these  assumptions  do  not 
fully  conform  to  the  various  designs  suggested  by  FAA  specialists  and 
others,  but  the  staffing  analyses  we  performed  required  operational 
descriptions  that  were  both  realistic  and  consistent  with  current  ATC 
development  programs.  Where  such  descriptions  were  not  available  in 
sufficient  detail,  we  postulated  development  of  the  necessary  operational 
procedures. 


C.  Method  of  Approach 

We  are  concerned  with  the  Impact  of  automation  on  ATC  capacity.  Based 
on  our  observations  of  ATC  operations,  we  concluded  that  in  almost  all  cases, 
the  limits  on  capacity  are  associated  with  controller  workload.  Hence,  we 
chose  to  focus  on  controllers,  controller  teams,  and  team  organization. 
Because  ATC  services  involve  complex  decision  making  by  many  people,  we  de- 
cided that  our  approach  had  to  be  based  on  measurements  of  present  opera- 
tions which  are  the  best  example  of  such  complex  decision  makings;  this 
provides  a realistic  base  from  which  to  develop  operating  descriptions  of 
possible  enhancement  systems.  Therefore,  we  used  operations  data  collected 
at  the  Oakland  Bay  and  Los  Angeles  TRACONs  where  Arts  III  was  in  full  use. 

Because  capacity  is  so  closely  related  to  controller  operations,  we 
have  expressed  the  effects  of  UG3RD  system  equipment  and  functions  in 
terms  of  the  changes  these  systems  would  effect  upon  present  controller 
workload.  Current  controller  operations  were  observed  in  the  field  at 
six  sectors  of  the  Oakland  Bay  TRACON  and  the  four  at  the  Los  Angeles 
TRACON;  these  data  were  used  in  developing  RECEP  models  that  estimate 
sector  capacity.  The  revised  controller  operations  expected  under  each 
alternative  UG3RD  system  were  then  fed  into  the  RECEP  model  to  determine 
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sector  capacity  for  each  alternative.  Sector  capacities  were  estimated 
for  both  visual  and  instrument  approach  conditions  and  for  alternative 
sector  team  manning  regimes.  For  each  ATC  system,  including  the  ARTS  III 
base,  the  capacity  data  were  then  used  to  estimate  the  number  of  radar 
and  handoff  positions--controllers,  coordinators,  parallel  monitors,  and 
flight  data  positions--needed  in  each  sector  to  handle  increments  in  pro- 
jected traffic.  These  estimates  are  made  separately  for  the  two  TRACON 
sites,  and  they  represent  manning  requirements  in  the  selected  multisector 
areas  for  the  day  shift  of  the  busy  day  (90th  percentile).  These  predicted 
manpower  needs  can  be  used  to  compare  the  potential  operational  impact  of 
the  UG3RD  systems. 

We  emphasize  that  these  manning  estimates  rely  heavily  on  the  validity 
of  the  RECEP  models.  The  basic  RECEP  technique  has  been  applied  to  16 
sectors  in  enroute  and  terminal  facilities,  while  the  RECEP  formula- 
tion as  used  in  this  report  has  been  applied  to  11  enroute  sectors  at  the 
Los  Angeles  and  Atlanta  Centers. In  all  cases,  the  resulting  RECEP 
capacity  estimates  were  consistent  with  estimates  made  by  facility  per- 
sonnel. Although  these  results  may  not  be  considered  a formal  validation 
of  the  RECEP  model,  they  do  indicate  that  it  is  a reasonable  representa- 
tion of  control  operations. 


D.  Organization  of  This  Report 

The  sections  of  this  report  may  be  grouped  in  three  parts,  although 
these  parts  are  not  formally  designated.  The  first  part,  which  includes 
this  section  and  Sections  II,  III,  and  IV,  is  Introductory  in  nature  and 
describes  terminal  ATC  and  workload  modeling  approaches.  The  second  part 
is  the  Oakland  Bay  TRACON  case  study.  Sections  V through  VIII.  The  third 
part,  Sections  IX  through  XII,  is  the  Los  Angeles  TRACON  case  study. 
Further  details  of  the  analysts  are  included  in  the  Appendix. 

In  the  first  part.  Section  II  describes  TRACON  control  operations 
and  procedures,  and  it  differentiates  between  arrival  operations  (includ- 
ing visual  and  instrument  approaches)  and  departure  operations.  Sec- 
tion III  describes  the  ARTS  III  system  and  the  associated  controller 
operating  requirements.  Section  IV  describes  the  analytical  approach 
used  to  model  terminal  operations  and  sector  workload  requirements. 

In  the  second  part.  Section  V describes  the  Oakland  Bay  TRACON' s 
sectorization  structure  and  arrival  and  departure  procedures.  Section  VI 
explains  the  data  collection  at  Bay  TRACON  and  the  construction  of  RECEP 
models  corresponding  to  ARTS  III  operations  for  the  six  sectors.  Sec- 
tion VII  describes  the  reconstruction  of  the  RECEP  models  according  to 
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UG3RD  system  operations.  Section  VIII  gives  the  sector  capacity  and 
manning  estimates  made  for  the  ARTS  III  and  UG3RD  system  alternatives. 


In  the  third  part,  Sections  IX,  X,  XI,  and  XII  are  analogous  to 
Sections  V,  VI,  VII,  and  VIII,  respectively,  but  they  address  the  Los 
Angeles  TRACON. 
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II  TRACON  OPERATIONS 


In  this  report  we  address  the  potential  impact  of  ATC  automation 
on  TRACON  operations,  as  distinguished  from  airport  traffic  control 
tower  (ATCT)  and  air  route  traffic  control  center  (ARTCC)  operations. 

The  terminal  airspace  controlled  by  a TRACON  operation  is  a transition 
zone  between  airports  and  enroute  airspace,  and  it  is  divided  into  volumes 
of  airspace  called  Lectors.  Each  sector  is  under  the  jurisdiction  of  a 
controller  or  team  of  controllers  who  maintain  radio  contact  with  and 
radar  surveillance  of  aircraft  within  the  sector.  Sectors  are  configured 
according  to  a system  of  airport  arrival  and  departure  routes,  and  the 
control  operations  for  each  sector  are  procedurally  structured  and  inte- 
grated with  each  other  to  facilitate  traffic  flow  and  separation  assurance. 

In  order  to  provide  an  overview  of  terminal  ATC,  we  first  discuss 
the  terminal  control  procedures  used  to  integrate  sector  control  responsi- 
bilities; and  secondly,  the  actual  operations  nature  of  TRACON  sectors. 

We  base  the  following  discussions  on  our  observation  of  Oakland  Bay  and 
Los  Angeles  TRACON  operations. 


A.  Terminal  Control  Procedures 


Although  each  sector  team  is  responsible  for  aircraft  within  its 
assigned  airspace,  air  traffic  control  operations  currently  depend  on  a 
well  defined  and  highly  structured  system  of  intersector  and  interfacility 
control  procedures  which  facilitate  the  orderly  movement  of  aircraft 
through  a multisector  environment.  Between  adjoining  sectors  and  facili- 
ties both  formal  letters-of-agreement  and  informal  accords  specify  the 
usual  aircraft  altitudes,  speeds,  headings,  and  in-trail  separations 
that  should  be  established  when  jurisdictional  control  over  aircraft  is 
transferred  from  one  sector  team  to  another  at  their  common  boundary; 
these  procedures  reinforce  an  established  system  of  preferential  traffic 
routes  and  standard  terminal  arrival  and  departure  patterns. 

The  intersector  agreements  provide  decision-making  guidelines  for 
sector-control  by  defining  the  traffic  flow  strategies  and  mechanisms  by 
which  jurisdiction  is  delegated  to  individual  sector  teams  without  re- 
quiring excessive  coordination  between  them.  For  example,  a control  team 
accepting  aircraft  at  its  sector  boundary  need  not  be  concerned  with  how 
the  preceding  sector  team  controlled  the  aircraft,  providing  it  is  properly 
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set  up  in  accordance  with  the  intersector  procedural  agreement.  Sector 
decisions  regarding  which  control  techniques  (e.g. , vectoring,  altitude, 
or  speed  instructions)  should  be  used  in  structuring  traffic  for  sector 
transit  and  exit  are  internal  functions  of  each  sector  team  and  do  not 
require  consultation  with  a facility  authority.  The  sector  teams  are 
essentially  autonomous  decision-making  units  operating  under  the  traffic 
organization  requirements  of  the  procedural  agreements;  supervisory, 
coordinating,  and  support  personnel  are  not  involved  in  minute-by-minute 
issuance  of  sector  control  instructions. 

The  system  of  procedural  agreements  and  preferential  routes  struc- 
tures each  sector's  traffic  flow  such  that  sector  control  becomes  somewhat 
standardized,  resulting  in  a fairly  stable  set  of  control  techniques. 
Controllers  make  decisions  concerning  an  individual  flight  plan  or  con- 
flict avoidance  maneuver  based  on  established  personal  knowledge  of  what 
is  best  for  facilitating  overall  traffic  flow;  they  do  not  spend  time 
reviewing  the  direct  implications  of  a single  control  instruction  upon 
each  and  all  aircraft  under  their  jurisdiction.  Familiarity  with  the 
procedural  requirements  of  each  sector  is,  therefore,  important  to  a 
control  team's  ability  to  make  control  decisions  with  minimum  effort. 

Procedural  agreements  clearly  document  facility  traffic  control 
policy  and  effectively  serve  as  a relatively  stable  traffic  planning 
device  for  sector  operations.  However,  flexibility  in  intersector 
traffic  integration  can  be  introduced  directly  between  adjacent  sector 
teams  or  facilities;  such  coordination  is  often  necessary  as  traffic 
situations  change.  A sector  team,  for  example,  may  request  another 
sector  team  to  adjust  spacings  between  aircraft  in  order  to  coordinate 
aircraft  sequences,  or  one  facility  may  request  another  to  constrain 
traffic  overloading  situations.  Similarly,  altitude  and  speed  restric- 
tions may  be  applied  or  removed  as  situations  warrant.  Again,  it  is 
important  to  emphasize  that  personnel  not  on  the  sector  team  do  not 
specify  which  control  techniques  should  be  applied,  but  only  issue 
specifications  or  negotiate  with  the  sector  team  regarding  overall 
traffic  flow  organization. 


B . Terminal  Sector  Operations 

TRACON  sector  controllers  provide  separation  assurance  and  traffic 
flow  facilitation  services  to  aircraft  arriving  and  departing  from  local 
airports  and  to  aircraft  transiting  the  terminal  airspace.  Controllers 
monitor  displays  of  radar-derived  situation  data,  make  decisions,  voice 
communicate  with  pilots  to  transmit  clearances,  maneuver  instructions, 
proximate  traffic  and  navigational  advisories  and  the  like,  communicate 
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with  other  controllers  to  coordinate  their  control  actions,  and  maintain 
computerized  and  hard-copy  data  records  describing  aircraft  flights. 

The  terminal  area  route  structure  is  designed  to  segregate  arrival 
traffic  flows  from  departure  traffic  flows  as  much  as  possible.  This 
policy  minimizes  conflicts  between  descending  and  climbing  aircraft, 
which  could  become  excessively  frequent  and  difficult  to  control  in  dense 
traffic  situations.  The  route  segregation  is  procedurally  achieved  by 
mea  is  of  formal  altitude  separation  (i.e.,  tunneling  one  route  under 
another)  and  geographic  separation  (i.e.,  defining  arrival  and  departure 
corridors).  In  some  terminal  areas,  especially  where  numerous  airports 
are  served,  the  complexity  of  the  required  route  network  and  the  con- 
straints of  airspace  preclude  the  complete  segregation  of  arrival  and 
departure  traffic.  However,  a degree  of  procedural  segregation  is 
normally  sufficient  to  enable  arrangement  of  sectors  along  predominantly 
inbound  and  outbound  routings.  As  a result,  TRACON  sectors  often  are 
differentiated  according  to  arrival  and  departure  operations. 


1 . Arrival  Operai-ions 


Arrival  traffic  flows  from  diverse  directions  are  integrated 
through  a series  of  merges.  These  merging  operations  require  arrival 
sector  controllers  to  determine  the  order  in  which  the  aircraft  are  to 
be  processed  through  the  merge  points  while  maintaining  proper  spacing; 
these  operations  are  aided  by  a system  of  procedural  specifications. 

Initial  route  mergings  are  conducted  in  the  enroute  airspace  by  the 
Center  in  order  to  organize  the  traffic  according  to  control  specifica- 
tions required  for  entering  the  terminal  airspace.  By  this  means,  air- 
craft are  brought  into  TRACON  arrival  sectors  along  defined  routes  in 
accordance  with  prespecified  or  individually  negotiated  in-trail  separa- 
tions (typically  5 n.m.)  and  often  according  to  specified  altitude  and 
speed  restrictions.  Arrival  sector  controllers  process  the  aircraft 
through  a succession  of  fewer  and  fewer  merge  points  until  the  traffic 
is  funneled  to  the  airport  final  approaches.  Control  jurisdiction  then 
is  transferred  to  the  tower  in  conformity  with  the  appropriate  in-trail 
separation,  speed,  and  altitude  specifications.  This  process  involves 
the  use  of  speed,  altitude,  and  vectoring  controls  to  slow  the  descending 
aircraft  to  approach  speed,  clear  them  along  their  planned  routes,  sequence 
them  through  the  merges,  and  space  them  to  maintain  separation. 

At  some  TRACONs  (such  as  Oakland)  arrival  operations  are  based 
on  the  "feeder  and  final"  sectorization  concept,  where  a feeder  sector's 
controller  accepts  aircraft  entering  from  an  ARTC  Center,  processes  the 
aircraft  through  his  airspace,  and  transfers  control  jurisdiction  of  the 
aircraft  to  a final  sector  controller.  The  final  sector  controller 
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maintains  control  of  the  aircraft  until  it  approaches  the  airport  run- 
ways, at  which  time  control  jurisdiction  is  transferred  to  a tower. 

In  this  operation,  a feeder  sector's  controllers,  and  not 
those  of  the  final  sector,  usually  determine  the  sequence  in  which  air- 
craft are  ordered  for  landing.  Because  the  feeders  control  the  merges 
located  in  their  airspace  and  are  responsible  for  the  sequencing  and 
spacing  of  aircraft  through  these  points,  they  control  the  order  and 
spacing  of  traffic  entering  the  final  sectors.  Thus  the  feeder  sector's 
control  decisions  determine  the  sequencing  of  aircraft  merging  at  down- 
stream points  located  in  the  final  sector.  In  this  way  the  feeder  con- 
trollers "set  up"  the  traffic  for  downstream  sequencing,  while  the  final 
sector  controllers  "fine-tune"  the  traffic  by  issuing  directives  needed 
to  complete  the  mergings,  maintain  separation,  and  proceed  to  landing. 
However,  if  necessary,  the  final  sector  controllers  have  the  option  of 
altering  the  traffic  sequencing  plan  established  by  the  feeders. 

At  other  TRACONs  (such  as  Los  Angeles) , control  operations  are 
not  delineated  according  to  feeder  and  final  sector  pairs;  these  functions 
are  performed  by  a single  designated  arrival  sector.  In  any  case,  the 
single  or  the  paired  sector  design  can  be  used  for  handling  traffic  in 
separate  and  possibly  parallel  corridors.  For  example,  one  arrival  sec- 
tor or  pair  of  sectors  may  control  aircraft  destined  to  a specific  run- 
way or  runway  complex,  while  another  sector  operation  controls  aircraft 
destined  for  other  runway(s).  Both  the  Oakland  Bay  and  Los  Angeles 
TRACONs  basically  have  such  a control  scheme:  two  traffic  corridors  run 
into  the  final  approaches  to  parallel  runways.  At  the  Oakland  Bay  TRACON, 
each  sector  feeds  into  its  own  runway,  while  the  Los  Angeles  TRACON  sec- 
tors feed  two  pairs  of  parallel  runways.  In  such  cases,  an  arrival  sec- 
tor or  a "feeder  and  final"  pair  may  operate  relatively  independent  of 
its  complementary  sector(s),  especially  during  visual  approach  condi- 
tions. However,  if  the  runway  configuration  is  such  that  the  aircraft 
on  the  parallel  approach  courses  are  in  lateral  proximity  with  each 
other,  special  precautions  must  be  taken  to  assure  adequate  aircraft 
separation  during  instrument  approaches.  Each  final,  feeder,  or  arrival 
sector's  controllers  must  coordinate  their  sequencing  and  soacing  opera- 
tions with  those  of  the  parallel  sector  to  integrate  traffic  for  mutual 
airport  approach. 

In  summary,  arrival  sector  operations  depend  on  the  traffic 
requirements  specific  to  each  TRACON  site.  We  see  that  controllers 
carry  out  local  merging  operations  for  aircraft  directly  under  their 
control,  but  also  influence  merging  situations  in  downstream  sectors. 
During  instrument  landing  operations,  controllers  must  overtly  coordi- 
nate approach  mergings  with  other  controllers;  such  coordination  may  not 
be  needed  during  visual  approach  operations.  Additionally,  sector 
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controllers  need  to  maintain  separation  assurance  for  aircraft  that  are 
potentially  In  crossing  or  overtaking  conflict  situations,  while  at  the 
same  time  facilitating  the  flight  of  all  aircraft — Including  those  merely 
crossing  the  alrspace--ln  accordance  with  pilot  plans  and  procedural 
requirements. 


2.  Departure  Operations 


Departure  sector  operations  differ  from  those  of  arrival  sec- 
tors only  In  that  aircraft  are  predominantly  diverging  rather  than  merg- 
ing. Departure  sector  controllers  accept  climbing  aircraft  from  an 
airport  tower,  process  the  aircraft  through  their  airspace,  and  transfer 
control  jurisdiction  to  an  ARTC  Center  as  the  aircraft  enter  enroute  air- 
space. Although  the  aircraft  are  received  from  one  or  a few  origin  air- 
ports, they  normally  have  different  destinations  and  therefore  are 
usually  on  divergent  routes  within  a departure  sector.  However,  some 
local  merging  may  occur  In  order  to  Integrate  take-offs  from  different 
runways  or  airports.  Although  parallel  departure  sectors  may  be  desig- 
nated (as  at  the  Oakland  Bay  and  Los  Angeles  TRACONs) , alternate  departure 
routes  are  sufficiently  separated  so  that  extensive  coordination  normally 
need  not  be  carried  out  between  controllers  of  different  departure  sec- 
tors. 


As  In  the  case  of  arrival  sectors,  a few  aircraft  may  be  cross- 
ing through  the  departure  airspace.  Controllers  need  to  separate  all 
aircraft  In  potential  crossing  and  overtaking  conflict  situations  as  well 
as  those  In  local  merging  situations,  and  facilitate  flight  planning. 
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Ill  ARTS  III  SYSTEM  DESCRIPTION 


The  current  third  generation  ARTS  III  system  is  the  base  from 
which  the  upgraded  ATC  systems  will  evolve.  To  enable  an  understanding 
of  the  potential  applications  and  limitations  of  automated  ATC  enhance- 
ments, we  first  describe  ARTS  III  operational  equipment  and  secondly, 
ARTS  III  control  operations.  These  descriptions  are  intended  to  provide 
an  insight  into  the  operating  characteristics  of  current  automation 
technology.  One  should  bear  in  mind  that  the  ARTS  III  system  is  the 
technological  mechanism  currently  used  by  controllers  in  carrying  out 
the  operations  described  in  the  preceding  section  of  this  report. 


A.  ARTS  III  Equipment 

ARTS  III  is  a semi -automated  terminal  ATC  support  system  whose 
major  elements  are  the  computerized  data  acquisition  subsystem  (DAS) , 
data  processing  subsystem  (DPS),  and  data  entry  and  display  subsystem 
(DEDS) . The  system  operates  in  conjunction  with  Airport  Surveillance 
Radar  (ASR)  and  Air  Traffic  Control  Beacon  Interrogators  (ATCBI)  to 
process  primary  radar  and  Air  Traffic  Control  Radar  Beacon  System 
(ATCRBS)  data.  ARTS  III  interfaces  with  the  computerized  Flight  Data 
Processing  (FPD)  system  to  enable  transfer  of  digitized  flight  data 
between  ATC  facilities. 

ARTS  III  hardware/software  apparatus  enables: 

• Beacon  tracking. 

• Broadband  radar/beacon  displays  with  alphanumeric  data 
blocks  (including  aircraft  identity.  Mode  C automatic 
altitude,  and  ground  speed  reports) . 

• Display  filtering. 

• Simplified  clearance/coordination  procedures. 
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Equipment  Applications 

The  ARTS  III  computer  system  tracks  the  trajectory  of  an  air- 
craft's ATCRBS  beacon  responses  to  successive  ATCBI  interrogations  (e.g. , 
at  4-second  intervals)  and  correlates  this  information  with  computer- 
stored  flight  plan  data.  This  flight  plan  correlation  enables  the  sys- 
tem to  recognize  the  identity  of  an  aircraft  replying  on  a selected  dis- 
crete beacon  code,  and  to  automatically  initiate  tracking  operations; 
controllers  must  manually  initiate  tracking  for  nondiscrete  beacon  tar- 
gets. The  ARTS  III  tracking  program  stores  positional  data,  calculates 
beacon  target  velocity,  predicts  flight  path  position,  and  correlates 
subsequent  beacon  responses  with  these  predictions.  Concurrently,  the 
computer  uses  manually  entered  altimeter  setting  data  to  decide  altitude 
data  from  Mode  C transponder  responses  to  interrogations.  Tracking  is 
automatically  discontinued  when  an  active  track  passes  a prespecified 
range  and  azimuth  or  manually  at  the  controller's  discretion. 

Flight  plan  data  are  obtained  automatically  from  other  FDP- 
equipped  facilities  through  established  computer  interfaces  or  are  en- 
tered manually  by  TRACON  controllers. As  Indicated  in  the  preceding 
paragraph,  the  flight  plan  data  record  is  used  to  establish  and  maintain 
automatic  tracking,  and  it  facilitates  target  correlation  and  identifica- 
tion. The  correlation  process  enables  the  ARTS  III  system  to  associate 
data  blocks  with  beacon  targets;  such  association  is  useful  for  display 
purposes.  This  display  capability  and  the  concurrent  computerized  data 
processing  are  the  basic  automation  attributes  of  ARTS  III;  these  at- 
tributes determine  the  design  of  the  operational  equipment  made  available 
to  sector  teams. 


2.  Equipment  Usage 

The  ARTS  III  system  supports  control  operations  through  the 
presentation  of  alphanumeric  data  on  sector  controllers'  radar  displays, 
the  semi-automatic  transfer  of  data  between  sectors,  and  the  automatic 
transfer  of  flight  data  between  the  terminal  and  ARTCC  computers.  These 
support  capabilities  are  provided  to  controllers  through  the  ARTS  III 
automation  devices  included  in  each  sector  team's  operating  console. 

An  ARTS  III  console  includes  a planned  view  display  (PVD) 
and  keyboard  and  trackball  units,  which  jointly  provide  a data  entry 
and  display  interface  between  the  controllers  and  the  computer  system. 
These  automation  elements  augment  sector  team  voice  communications  and 
hard-copy  (paper)  data  processing  equipment. 
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The  PVD  presents  radar-derived  aircraft  situation  data  and 
computer-processed  alphanumeric  and  symbolic  data.  The  presentation  may 
include  primary  radar  targets,  beacon  targets,  control  position  symbols, 
aircraft  data  blocks  (from  beacon  targets  only),  video  maps,  tabular 
lists  (i.e.,  arrival/departure  and  coast/suspend  lists),  time,  altimeter 
setting,  selected  beacon  codes,  general  system  information  (e.g.,  ATIS, 
weather)  and  the  like.  The  PVD  may  be  vertical  (Type  I console)  or 
horizontal  (Type  II  console) , with  adjustment  knobs  to  control  bright- 
ness range,  alphanumeric  character  size,  and  so  forth. 

A trackball  and  keyboard  unit  operates  in  conjunction  with 
the  PVD  and  provides  the  controller-computer  interface  mechanisms  for 
data  entry  and  display  control.  The  unit  includes  a trackball  panel, 
alphanumeric  keys  and  quick-action,  special  function  keys.  The  track- 
ball is  used  manually  to  slew  and  capture  PVD  targets,  while  manual 
keypunching  is  used  to  access  the  computerized  operation.  These  capa- 
bilities enable  controllers  to  select  and  revise  data  presented  on  the 
PVD,  enter  flight  data,  and  carry  out  special  control  operations  (e.g., 
transfer  control  jurisdiction,  manually  initiate  or  drop  beacon  tracking) . 
At  least  one  trackball  and  keyboard  unit  is  built  into  each  console,  but 
additional  keyboard-only  units  may  be  provided  (normally  with  the  Type  II 
horizontal  display). 

The  console  designs  vary  from  facility  to  facility  in  accordance 
with  local  operations.  At  some  facilities  (such  as  the  Boston-Logan 
TRACON) , vertical  PVDs  and  associated  keyboard  and  trackball  units  are 
arranged  in  rows,  with  one  PVD  console  assigned  to  each  sector  team.  At 
other  facilities,  sector  team  pairs  are  set  up  as  islands  isolated  from 
other  sector  team  pairs.  In  this  case,  each  team  usually  is  equipped 
with  its  own  PVD  console  (as  at  the  Los  Angeles  TRACON  where  both  horizon- 
tal PVD  and  vertical  PVD  pairs  exist).  At  least  one  facility  (Oakland 
Bay  TRACON)  has  a single  PVD  island  shared  by  two  sector  teams,  but  each 
team  is  equipped  with  its  own  trackball  panel  and  keyboards. 

In  addition  to  the  ARTS  III  automation,  the  sector  console 
includes  air/ground  (A/G)  radio  and  interphone  communications  apparatus 
and  workspace  for  maintaining  paper  flight  progress  strips  or  scratch 
pad  hard-copy  data  records.  A/G  communications  enable  two-way  voice 
conversation  between  pilot  and  controller,  while  interphone  communica- 
tions enable  two-way  voice  conversations  between  controllers  of  different 
sectors  as  well  as  between  different  facilities.  Hard-copy  records  pro- 
vide flight  data  information  to  supplement  PVD-displayed  data,  and  they 
are  manually  updated  in  handwriting.  Paper  flight  strips  are  prepared 
by  FDP  printer  or  prepared  manually  by  sector  controllers;  some  sector 
teams  use  paper  scratch  pads  in  lieu  of  formal  flight  strips. 
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B.  ARTS  III  Operations 

We  now  examine  the  way  in  which  the  ARTS  III  equipment  is  used  to 
carry  out  sector  team  control  operations  and  the  options  available  in 
assigning  control  responsibilities  among  sector  team  members. 


1 . Sector  Control  Operations 


The  sector  control  team  utilizes  the  ARTS  III  console  to  con- 
duct separation  assurance  and  facilitate  traffic  flow.  In  this  opera- 
tion, the  controllers  are  the  primary  decision  makers  and  use  the  ARTS  III 
console  to  obtain  and  transfer  information.  The  ARTS  III  automation  does 
not  make  control  decisions,  but  it  supports  the  controllers'  decision- 
making processes  by  automatically  processing  and  displaying  flight  data 
and  facilitating  communications.  The  following  discussion  reviews  the 
means  by  which  a sector  controller  interacts  with  the  ARTS  III  system, 
with  pilots,  and  with  other  controllers  in  order  to  effect  control  ser- 
vices and  implement  procedural  requirements. 

The  PVD's  alphanumeric  aircraft  data  block  information  serves 
as  an  aid  to  the  controller's  awareness  of  current  and  planned  traffic 
situations,  and  it  becomes  increasingly  important  as  sector  traffic 
levels  rise.  The  data  block  presents  aircraft  flight  identity,  current 
altitude,  and  ground  speed  information  that  trigger  an  instant  recall 
of  each  aircraft's  current  and  planned  flight  path.  This  mnemonic  effect 
is  particularly  useful  to  a controller  who  must  cope  with  dynamic  traffic 
data.  A controller  can  concentrate  attention  on  traffic  presented  in  one 
area  of  the  PVD,  while  other  data  are  automatically  being  updated  without 
controller  assistance.  The  alphanumeric  data  blocks  are  also  useful  in 
establishing  the  target  identities  of  aircraft  not  yet  under  the  sector 
team's  jurisdiction. 

The  controller  relies  on  continuous  PVD  surveillance  to  men- 
tally project  flight  trajectories  and  conduct  limited  conflict  searches; 
his  picture  of  current  and  future  traffic  situations  includes  a concep- 
tual overlay  of  the  standardized  control  procedures  (Including  minimum 
separation  requirements)  and  preferential  routes  as  well  as  a thorough 
knowledge  of  aircraft  performance  characteristics  (which  depend  on  air- 
craft design  and  owner  operating  policies).  In  order  to  formulate  control 
decisions,  the  controller  mentally  compares  his  traffic  projections  against 
the  traffic  structuring  guidelines  specified  by  the  control  procedures. 

His  control  decisions  are  then  disseminated  by  means  of  A/G  communications. 
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The  controller's  mental  "picture-keeping"  process  is  also 
supported  by  hard-copy  data,  usually  paper  flight  progress  strips  but 
sometimes  paper  scratch  pads.  The  flight  strips  describe  each  air- 
craft's flight  identity,  route,  altitude,  speed  plans,  beacon  code 
assignment,  and  equipment.  This  basic  information  supplements  the  PVD 
data  blocks  by  indicating  flight  plans  and  aircraft  capabilities  that 
a controller  must  know  when  an  incoming  aircraft  is  added  to  his  mental 
picture  of  the  traffic  situation.  Flight  strips  may  be  used  for  manual 
recording  of  such  control  actions  as  altitude  clearance,  route  revisions, 
or  beacon  code  changes.  In  some  cases,  where  sector  procedures  are  ex- 
tremely structured  (e.g. , final  approach  sectors),  only  the  sequence  in 
which  aircraft  enter  and  depart  the  sector  need  be  recorded  on  scratch 
pads.  Hard-copy  data  also  serve  an  important  failure-mode  function  for 
surveillance.  In  the  event  of  a complete  failure  in  the  radar  data 
presentation  capability,  the  paper  data  may  be  used  in  conjunction  with 
pilot  reports  for  on-line  flight  following  by  the  controllers. 

A controller  also  issues  control  instructions  to  pilots  by  voice 
communicating  over  A/G  radio.  Such  verbal  instructions  include  clearances 
(i.e.,  assignments  or  approvals  of  specific  routes,  altitudes,  and  speeds), 
advisories  (i.e.,  weather,  proximate  traffic  information),  and  direct  navi- 
gational control  (i.e.,  heading  vectors  and  altitude  or  speed  revisions). 
Direct  voice  communication  provides  some  flexibility  because  it  allows 
pilots  to  negotiate  with  a controller  if  the  instruction  issued  cannot 
be  readily  followed;  positive  confirmation  of  instruction  compliance  is 
also  transmitted  by  voice.  Since  most  aircraft  in  a sector  are  on  the 
same  radio  frequency,  the  A/G  communication  is  on  a "party-line"  with 
aircraft  crews  monitoring  each  other's  instructions  and  responses.  Al- 
though not  studied  explicitly  here,  pilots  may  perhaps  use  this  capability 
to  communicate  among  themselves  in  order  to  attempt  separation  assurance 
should  a ground-based  A/G  system  totally  fail. 

Controllers  communicate  with  each  other  by  means  of  interphone 
voice  or  face-to-face  coordination.  The  interphone  system  is  used  to 
negotiate  and  confirm  procedural  controls  (i.e.,  arrival  sequences,  speed, 
or  altitude  restrictions,  in-trail  separations)  and  to  advise  sector  teams 
of  some  specific  traffic  condition  that  may  be  unusual.  Members  of  a 
single  sector  team  or,  in  certain  cases,  members  of  adjacent  sector  teams 
may  communicate  directly  with  each  other  by  face-to-face  oral  conversa- 
tions (i.e.,  without  interphone  apparatus)  or  with  hand  signals  (i.e., 
by  pointing  to  a PVD  target  or  moving  a flight  strip).  As  in  the  case 
of  interphone  intersector  messages,  these  communications  are  needed  to 
coordinate  controller  actions  so  that  each  controller  maintains  cogni- 
zance of  overall  operations  and  thereby  avoids  last-minute  surprises. 
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A sector  controller  uses  the  computer  data  entry  and  display 
interface  to  carry  out  various  control  operations  and  keep  the  automa- 
tion system  up  to  date  concerning  his  on-line  control  operations.  For 
example,  manual  trackball  and  keyboard  operations  are  used  to  effect 
control  jurisdiction  transfers  between  sectors;  these  transfers  are 
usually  performed  silently  without  accompanying  interphone  voice  com- 
munication, Such  "handoffs"  are  registered  in  the  computer  system, 
which  in  turn  transfers  data  file  access  from  one  control  team  to  another 
and  updates  PVD  position  symbol  displays.  In  other  cases,  the  controller 
may  use  the  data  entry  and  display  system  to  manually  enter  or  modify 
flight  plan  data  into  computer  storage,  assign  a discrete  beacon  code, 
or  establish  beacon  tracking.  A controller  may  selectively  force  the 
presentation  of  individual  data  blocks  on  to  his  PVD  or  delete  them, 
or  he  may  force  the  entire  PVD  data  for  another  sector  onto  his  display 
in  order  to  "glance  over"  that  sector's  traffic.  Controllers  also  have 
the  option  to  use  an  alphanumeric  "scratch  pad"  which  electronically 
displays  such  data  as  destination  airport,  runway,  or  departure  fix 
designations;  this  scratch  pad  information  time  shares  PVD  data  block 
display  space  with  the  Mode  C altitude  data.  (The  PVD  "scratch  pad" 
should  not  be  confused  with  the  paper  scratch  pad.)  Other  operations 
enable  controllers  to  display  tabular  lists,  reorient  data  block  presen- 
tations, preview  flight  plan  data,  present  system  data  on  the  PVD,  and 
so  forth.  These  examples  demonstrate  some  of  the  uses  made  of  the  track- 
ball and  keyboard  units,  which  provide  the  means  to  integrate  computer 
processing  capabilities  with  sector  control  operations. 


2.  Sector  Controller  Responsibilities 

The  lead  member  of  an  ARTS  III  sector  team  is  the  radar  (R) 
controller,  who  is  responsible  for  separation  assurance,  minute-to-minute 
decision  making,  and  A/G  voice  communications.  He  may  be  supported  by  a 
coordinator,  by  a handoff  (H)  controller,  or  by  both.  During  periods  of 
light  traffic,  the  R controller  may  man  the  sector  alone  and  therefore 
perform  all  necessary  communications  and  data  processing  activities. 
However,  as  traffic  increases,  the  R controller's  workload  restricts  his 
performance,  necessitating  the  allocation  of  some  operational  activities 
to  one  or  both  of  the  other  team  members. 

While  a single  H controller  may  be  assigned  to  assist  an  R 
controller,  a coordinator  is  assigned  to  a pair  of  sectors  and  simul- 
taneously supports  both  R controllers.  As  a result  of  the  shared  nature 
of  coordinators'  services,  we  refer  to  sector  team  manning  alternatives 
according  to  four  regimes:  a 1-man  team  (R  controller);  a 1,5-man  team 
(R  controller  and  one-half  the  services  of  a coordinator) ; a 2-man  team 
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(R  and  H controllers);  and  a 2. 5 -man  team  (R  and  H controllers  and  one- 
half  the  services  of  a coordinator). 

The  ARTS  III  console  is  usually  set  up  so  that  each  controller 
and  coordinator  position  is  equipped  with  keyboard  and  interphone  appara- 
tus, while  a single  PVD  and  trackball  panel  is  directly  accessible  by  the 
R controller.  Each  R controller  is  equipped  with  A/G  apparatus,  while 
all  sector  team  members  may  handle  flight  strips  or  paper  scratch  pads 
depending  on  local  operating  procedures.  These  equipment  arrangements 
enable  the  effective  division  of  control  responsibility  among  team  mem- 
bers. In  the  following  paragraphs  we  briefly  review  the  operational  role 
of  each  member  of  the  team  and  address  other  support  positions. 


a.  1-Man  Team 


The  R-controller  performs  all  the  sector  control  operations 
necessary  for  separation  assurance  and  traffic  flow  facilitation.  These 
operations  include  surveillance,  A/G  communications,  data  entry  and  dis- 
play, flight  strip  (or  paper  scratch  pad)  processing,  intersector  inter- 
phone and  face-to-face  coordination,  and  related  decision  making. 


b.  1 . 5-Man  Team 


The  R-controller  maintains  responsibility  for  separation 
assurance  and  minute-to-minute  decision  making,  but  shares  decision 
making  about  traffic  planning  with  the  coordinator.  The  coordinator  per- 
forms intersector  coordination  wnd  some  data  entry  operations,  while  the 
R controller  performs  separation  assurance,  surveillance  and  related  data 
processing  operations.  Based  on  our  observations  of  control  activities, 
the  coordinator  is  usually  able  to  perform  the  interphone  communications 
for  both  the  sectors  he  supports  and  half  the  computerized  handoffs  for 
each  sector.  However,  these  activities  do  induce  some  additional  face- 
to-face  communications  with  the  R controllers  since  he  must  advise  the 
R controller  regarding  the  intersector  negotiations  completed.  A co- 
ordinator supporting  a pair  of  arrival  sectors  determines  the  sequence 
in  which  aircraft  should  be  mutually  merged  and  advises  each  R controller 
of  his  plan;  each  R controller  sets  up  this  traffic  in  accordance  with 
the  coordinator's  plan.  A coordinator  supporting  a pair  of  departure 
sectors  integrates  tower  departure  operations  with  those  of  each  sector. 
Such  interfacility  coordination  is  also  performed  for  arrival  sectors, 
and  also  is  conducted  with  adjacent  ARTC  Centers.  Also,  the  coordinator 
may  assist  in  distributing  flight  strips  to  the  appropriate  R controller. 
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c. 


2-Man  Team 


The  R controller  maintains  responsibility  for  separation 
assurance  and  traffic  flow  facilitation,  and  shares  some  of  the  mechanical 
aspects  of  control  operations  with  the  H controller.  In  this  case,  the 
H controller  supports  only  one  R controller  and  should  have  time  to  per- 
form the  routine  interphone  communications  and  computer  handoff  operations. 
However,  the  R controller  must  himself  coordinate  separation  assurance  and 
sequencing  for  aircraft  merging  into  other  sectors  while  performing  sur- 
veillance and  communications  and  data  processing  activities.  Again,  intra- 
sector face-to-face  communications  is  needed  to  maintain  operational  cog- 
nizance of  each  team  member's  activities.  The  H controller  may  also 
assist  the  R controller  by  arranging  and  correcting  flight  strips.  We 
should  note  that  we  have  not  observed  a 2-man  team  in  actual  operations, 
indicating  that  TRACON  personnel  prefer  the  manning  strategies  which  in- 
volve a coordinator.  However,  since  2-man  teams  are  physically  and  opera- 
tionally possible,  we  do  consider  this  manning  option  to  be  feasible. 


d.  2. 5-Man  Team 


The  R controller  maintains  responsibility  for  separation 
assurance  and  minute-to-minute  decision  making,  but  he  shares  decision 
making  about  traffic  planning  with  the  coordinator  and  affords  some  of 
the  mechanical  control  tasks  to  the  H controller.  The  coordinator  is 
primarily  concerned  with  integrating  intersector  and  interfacility  opera- 
tions and  is  therefore  active  in  interphone  and  face-to-face  communica- 
tions; he  also  assists  in  flight  strip  distribution  where  appr'- iriate. 

The  H controller  performs  interphone  communications  not  handled  by  the 
coordinator,  carries  out  computer  data  entry  and  display  operations,  and 
may  assist  the  R controller  with  flight  strip  preparation. 


e.  Other  Support  Positions 

Although  not  directly  associated  with  a specific  sector, 
a controller  may  normally  man  a flight  data  position,  where  flight 
progress  strips  are  printed.  He  checks  and  corrects  flight  strip  data 
and  delivers  the  flight  strips  to  the  proper  sector  team  or  team  pair. 

In  some  cases,  the  delivery  is  made  to  an  arrival  or  departure  coordina- 
tor, who  selectively  distributes  strips  to  an  R controller  when  aircraft 
entry  is  about  to  occur.  In  at  least  one  facility  (Los  Angeles  TRACON) , 
flight  strip  printers  are  located  at  each  departure  sector  and  are  operated 
by  the  sector  H controllers.  In  this  case,  no  separate  flight  data  posi- 
tions are  currently  manned,  and  the  arrival  sectors  must  manually  write 
their  own  flight  strips.  In  other  cases  (such  as  final  arrival  sectors 
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at  Oakland  Bay  TRACON) , R controllers  use  paper  scratch  pads  to  keep 
track  of  aircraft  entries  and  exits;  FDP  printed  flight  strips  for 
arrival  aircraft  are  delivered  to  the  feeder  sectors  but  not  to  the 
finals. 

At  the  Los  Angeles  TRACON,  parallel  monitor  (PM)  positions 
are  manned  during  instrument  approach  operations.  A PM  controller  main- 
tains surveillance  of  aircraft  on  a set  of  parallel  final  approach  courses 
and  intervenes  on  the  arrival  sector's  A/G  radio  frequency  to  correct 
potential  violations  of  minimum  separations.  A PM  position  is  located  at 
a PVD  console  other  than  one  being  used  by  the  regular  sector  teams. 


IV  WORKLOAD  MODELING 


The  preceding  two  sections  have  described  terminal  ATC  control  pro- 
cedures, operations,  and  operational  technology.  In  this  section  we 
present  a methodology  for  quantitatively  relating  these  procedures, 
operations,  and  technology  to  the  traffic  handling  capabilities  of 
sector  controllers.  This  methodology  models  controller  workload  require- 
ments based  on  observations  of  ARTS  III  operations,  and  enables  estima- 
tion of  sector  controller  traffic  capacities  corresponding  to  various 
operating  strategies.  The  resulting  RECEP  models  will  facilitate  subse- 
quent extrapolations  and  analysis  of  the  impact  on  control  operations  of 
ATC  enhancement  alternatives. 


A.  Model  Overview 


In  order  to  relate  sector  traffic  handling  capabilities  to  the 
various  operating  strategies,  we  will  develop  workload  models  correspond- 
ing to  each  of  the  four  alternative  sector  manning  regimes:  1-man, 
1.5-man,  2-man,  and  2.5-man  teams.  Our  modeling  approach  will  follow 
that  of  our  previous  ATC  analyses^"^  in  which  we  used  data  collected 
from  field  observations  of  sector  teams  to  construct  the  models,  and 
thereby  to  describe  controller  work  characteristics. 


A major  assumption  of  our  approach  is  that  the  workload  on  the 
controller  due  to  his  operational  requirements  is  the  factor  which  limits 
the  number  of  aircraft  that  he  can  handle  during  any  given  period  of 
time;  this  thus  determines  the  traffic  capacity  of  the  sector.  Our  past 
observations  of  air  traffic  control  activities  indicate  that  within  a 
given  time  period  (i.e.,  one  hour)  there  is  a maximum  total  time  that 
a controller  can  spend  performing  control  tasks.  Through  previous  fiel  ’ 
observations  and  data  calibration  efforts,  we  have  found  that  an 
R controller's  workload  threshold  is  tynically  48  man-min  of  work  per 
hour;  the  number  of  aircraft  per  hour  that  generates  this  amount  of 
work  represents  his  traffic  capacity.  The  objective  of  our  models  is 
to  correlate  workload  time  requirements  with  traffic  flow  rates  so  that 
we  may  identify  the  traffic  flow  rate  (i.e.,  capacity)  corresponding  to 
the  workload  threshold  (48  man-min/hr) . We  use  an  hourly  time  period  as 
a basis  for  estimating  capacity  since  this  interval  is  the  time  a con- 
troller normally  spends  at  a sector  position  before  being  relieved. 
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The  following  discussion  reviews  the  procedures  for  field  data 
collection  and  describes  the  methods  and  rationale  with  which  the  data 
were  used  to  structure  workload  models. 


1 . Field  Experimentation 

Using  as  a guideline  our  previous  data  collection  exercises  at 
NAS  Stage  A enroute  ATC  facilities,^  ^ we  have  developed  a parallel 
data  col  lection/reduction  procedure  for  ARTS  III  terminal  ATC  facili- 
ties based  on  the  following  data  sources: 

• Videotape  recordings  of  PVD  data,  using  an  auxiliary 
console  to  duplicate  in  real  time  the  presentation  on 
an  operational  PVD. 

• Audiotape  (including  videotape  sound  track)  recordings 
of  A/G  and  interphone  communications. 

• Manual  recordings  of  the  frequency  of  observed  con- 
troller actions,  including  data  entry  and  display 
operations,  flight  strip  or  paper  scratch  pad  process- 
ing, and  face-to-face  communications. 

• Manual  stopwatch  recordings  of  observed  controller 
actions . 

• Reproductions  of  flight  strips  and  paper  scratch 
pads,  used  and  marked  on  by  controllers. 

These  data  were  collected  during  a one-hour  observation  of  a 
selected  sector's  control  activities.  Each  observation  session  was 
followed  by  a one-hour  structured  interview  with  the  sector's  controllers. 
The  interviewer  used  videotape  playback  during  examination  and  discussion 
of  the  operational  strategies,  procedures,  and  techniques  employed  by  the 
controllers.  This  information  was  supplemented  by  published  facility 
operations  manuals,  letters-of-agreement,  maps,  and  the  like,  as  well  as 
consultations  with  facility  supervisory  personnel. 

Reducing  the  field  observation  data  involved  assembling  the 
data  measurements  into  a format  that  facilitates  cross-reference  of  the 
observed  activities  and  permits  a reconstruction,  in  part,  of  the 
various  control  activities.  The  information  on  operational  procedures 
obtained  during  the  controller  interview,  along  with  the  data  observa- 
tions, provided  perspective  on  control  requirements  that  was  useful  in 
the  logical  reconstruction  of  control  activity. 
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Also,  as  part  of  the  data  reduction  efforts,  we  obtained  stop- 
watch measurements  of  recorded  communications,  to  supplement  the  activity- 
time measurements  made  at  the  facility.  For  each  identified  task,  we 
selected  from  the  data  measurements  a "reasonable"  minimum  task  performance 
time  to  represent  task  work  requirements.  In  determining  minimum  per- 
formance times,  we  considered  only  those  observed  or  recorded  activities 
that  we  judged  were  performed  completely  (that  is,  they  satisfied  the 
requirements  of  information  transaction  or  message  content)  and  with 
efficiency  (without  delay,  interruption,  or  extraneous  information). 

Since  the  field  data  collection  sessions  were  generally  conducted  during 
moderate-to-heavy  conditions,  we  have  assumed  that  our  reconstruction 
of  control  activities  is  representative  of  control  requirements  during 
capacity  conditions  (during  which  nonessential  activities  are  minimized). 


2.  Model  Rationale 


Using  our  observations  on  control  operations  and  interviews 
with  facility  controller  and  supervisory  personnel,  we  conclude  that  the 
R controller's  workload  is  the  critical  determinant  of  sector  team 
traffic  capacity.  That  is,  the  R controller,  rather  than  the  coordina- 
tor or  H controller,  is  the  team  member  whose  workload  requirements  will 
limit  traffic  handling  capabilities.  We  base  these  conclusions  on  the 
observation  that  a significant  proportion  of  terminal  ATC  control  work 
is  centered  on  surveillance,  minute-to-minute  decision  making,  and  A/G 
communications;  these  tasks  are  not  off-loaded  to  other  positions  under 
any  of  the  alternative  sector  team  manning  regimes.  Therefore,  we  will 
develop  an  R controller  workload  model  corresponding  to  each  of  the  four 
sector  manning  regimes;  the  regimes  will  be  differentiated  by  changes 
in  the  model  reflecting  the  revised  operations  of  the  R controllers 
each  time  an  additional  controller  or  coordinator  is  added  to  the  team. 

In  each  case,  the  R controller's  workload  threshold  will  be  used  to  de- 
fine the  sector  team's  traffic  capacity. 

Out  emphasis  on  the  R controller  model  differs  from  the  ap- 
proach we  used  in  modeling  enroute  operations;*"^  then  we  modeled  R con- 
troller and  sector  team  work  separately.  Our  field  observations  indicate 
that  enroute  operations  make  more  extensive  use  of  computer  data  entry 
and  flight  strip  processing  than  terminal  operations.  The  distribution 
of  work  among  enroute  sector  team  members  would  in  some  instances  cause 
a sector  data  (D)  controller  to  experience  heavier  work  loading  than  the 
R controller  at  comparable  traffic  levels.  In  this  case,  the  overall 
team  work  requirements  rather  than  those  of  the  R controller  alone  would 
limit  traffic  handling  capability. 


B . Model  Structure 


In  a preceding  section  we  described  the  various  operational  activi- 
ties (i.e.,  decision  making,  surveillance,  communications,  data  process- 
ing) that  are  required  of  the  R controller.  These  activities  are  mutually 
integrated  and  interactive  and  are  very  difficult  to  model  as  independent 
entities.  Therefore,  we  aggregate  the  various  control  work  requirements 
into  activity  categories  that  represent  operational/procedural  relation- 
ships. For  our  modeling  purposes,  we  organize  control  requirements 
according  to: 

• Routine  work 

• Surveillance  work 

• Conflict  processing  work. 

Routine  work  includes  the  A/G,  interphone,  and  face-to-face  com- 
munications, data  entry/display  operations,  and  flight  strip  or  paper 
scratch  pad  data  processing  tasks  needed  to  facilitate  traffic  flow. 
Surveillance  work  is  the  visual  observations  of  the  PVD  data  to  facili- 
tate flight-following.  Conflict  processing  work  includes  the  decision 
making  and  communications  needed  to  detect  and  assess  potential  conflicts, 
resolve  the  conflicts  by  means  of  A/G  communications,  and  coordinate  the 
assessment  and  resolution  actions  with  other  controllers.  We  further 
categorize  potential  conflicts  according  to  crossing,  local  merging, 
overtaking,  and  coordinated  approach  merging  situa-_ons. 

R controller  workload  time,  Wj^,  measured  in  man-min/hr,  correspond- 
ing to  a specified  hourly  traffic  rate  is  calculated  using  the  following 
additive  formulation: 

= I k N + ct  N + (k„  + 

R L 1 s V 2 

where 

N is  the  number  of  aircraft/hr 

t is  the  average  sector  flight 
s 

c is  the  surveillance  workload 
aircraf t-min. 

k^  is  the  routine  workload  weighting,  measured  in  man-sec/ 
aircraft. 

k^  is  the  crossing  conflict  workload  weighting,  measured  in 
(man-sec/hr)  / (aircraf t/hr) 


"3  + k*  + k; 


) j^60 


through  the  sector, 
time,  measured  in  min. 
constant,  measured  in  man-sec/ 
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is  the  local  merging  conflict  workload  weighting,  measured 
3 9 

in  (man-sec/hr) / (a ircraft/hr). 

k,  is  the  overtaking  conflict  workload  weighting,  measured  in 
/|  _ 

(man-sec/hr) /(aircraft/hr) 2. 


is  the  coordinated  approach  merging  conflict  workload 
weighting,  measured  in  (man-sec/hr) / (aircraft/hr) 2, 


60  is  the  factor  to  convert  man-sec/hr  of  work  to  man-min/hr. 


A set  of  four  R-controller  workload  times  (W^' s)  is  calculated  for 
each  sector  corresponding  to  the  four  manning  regimes.  The  reginies  are 
distinguished  by  adjusting  the  workload  weighting  parameters  (k's). 

The  importance  of  the  workload  component  structure  of  the  R con- 
troller model  is  the  capability  of  distinguishing  the  control  work  re- 
quirements of  different  sectors  in  a manner  that  is  sensitive  to  each 
sector's  operational  characteristics.  Sector  routine  workload  time  (kj^N) 
increases  in  direct  proportion  to  the  traffic  flow  rate,  but  varies  from 
one  sector  to  another  depending  on  the  pattern  of  traffic  flow  through 
each  sector  as  well  as  each  sector's  procedural  rules.  For  example,  the 
routine  workload  weighting  (k|^)  for  an  arrival  sector  (where  speed  con- 
trol instructions  are  frequent)  would  differ  from  that  of  a departure 
sector  (where  speed  control  is  not  as  frequent) . 

The  surveillance  workload  time  (ctgN)  increases  in  direct  proportion 
to  sector  flight  time;  therefore,  surveillance  work  is  sensitive  to  the 
geographic  size  of  a sector  as  well  as  the  traffic  flow  rate.  The  flight 
time  parameter  (tg)  distinguishes  the  surveillance  work  requirements  of 
different  sectors  since  the  same  surveillance  workload  constant  (c)  ap- 
plies to  each  sector.  We  note  that  the  product,  ctg,  may  be  considered 
to  be  the  surveillance  workload  weighting  measured  in  man-min/aircraft. 


Potential  crossing,  local  merging,  overtaking,  and  coordinated  ap- 
proach merging  conflict  processing  workload  times  (k2N2,  k^N^,  k^N^,  and 
k^N^)  increase  with  the  square  of  the  traffic  flow  rate.  The  conflict 
workload  weightings  (k2,  k^,  k^,  and  k^)  calculated  for  one  sector  would 
differ  from  those  of  another,  depending  on  the  complexity  of  each  sector's 
route  structure  and  its  procedural  rules.  In  particular,  the  derivations 
of  the  conflict  workload  weightings  can  model  a variety  of  aircraft  cross- 
ing and  merging  situations  including  level/level,  level/climb,  climb/ 
climb,  level/descent,  and  so  forth. 

In  the  following  paragraphs  we  review  the  derivation  of  the  workload 
weightings. 
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1. 


Routine  Work 


The  routine  workload  time  (kj^N)  represents  the  ordinarily 
occurring  control  events  required  to  clear  aircraft  through  the  sector; 
it  is  generated  in  some  form  by  every  flight.  Using  the  field  data  col- 
lected for  each  sector,  we  Identify  the  routine  control  events,  specify 
the  set  of  tasks  required  to  effect  each  event,  determine  minimum  task 
performance  times,  and  measure  the  frequency  of  each  event  by  sector. 

Each  routine  event  is  included  in  one  of  the  following  func- 
tional categories: 

• Control  jurisdiction  transfer 

• Traffic  structuring 

• Pilot  request 

• General  intersector  coordination 

• General  system  operation. 

Control  jurisdiction  transfer  encompasses  the  collection  of 
control  events  required  to  handoff  an  aircraft  from  one  sector  to  another. 
Traffic  structuring  refers  to  the  procedural-based,  decision-making  pro- 
cess of  guiding  aircraft  through  a sector.  Pilot  requests  result  in 
real-time  flight  modifications,  adding  work.  General  intersector  coordi- 
nation includes  those  informational  transfers  that  are  performed  to  remain 
cognizant  of  multisector  traffic  movement,  but  are  not  part  of  handoff, 
traffic  structuring,  pilot  request,  or  pointout  activities.  General  system 
operation  refers  to  the  remaining  activities  not  included  in  the  above 
categories,  activities  such  as  PVD  display  maintenance. 

A routine  event  consists  of  a single  task  or  sequence  of  tasks 
that  must  be  performed  to  complete  the  event.  The  tasks  are; 

• A/G  communications 

• Data  entry/display  operations 

• Paper  flight  strip  (or  paper  scratch  pad)  processing 

• Interphone  communications 

• Face-to-face  communications. 

For  example,  one  control  event  routinely  required  for  control 
jurisdiction  transfer  is  handoff  acceptance.  This  event  requires  the 
controller  to  perform  manual  data  entry/display  operations  and  flight 
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strip  processing  tasks.  On  the  other  hand,  an  altitude  instruction 
event  issued  by  the  controller  as  part  of  the  traffic  structuring  func- 
tion might  involve  only  the  A/G  communication  task. 


Our  field  observation  results  enable  us  to  specify  individual 
task  times  and  the  frequency  of  each  event  by  sector  for  any  given  manning 
regime.  We  use  these  data  to  calculate  the  routine  workload  weighting. 


k 


1 


r t.  . 


where 


r . 
1 


is  the  frequency  of  occurrence  of  type  i routine  event 
measured  in  events/aircraft. 


t^j  is  the  minimum  performance  time  required  for  each  type 
j task  included  in  routine  event  i,  measured  in  man-min/ 
event,  (In  subsequent  modeling  applications,  we  will 
describe  task  times  by  man-sec;  conversion  to  man-min  is 
implicit  in  the  modeling  equations.) 


2.  Surveillance  Work 

Surveillance  workload  time  (ct^N)  is  the  time  spent  scanning 
the  PVD.  We  were  not  able  to  measure  in  the  field  the  number  of  times 
a controller  looks  at  the  PVD  or  the  duration  of  each  glance.  Instead, 
we  inferentially  formulated  assumptions  regarding  surveillance  frequency 
and  time  duration;  these  assumptions  are  developed  from  interviews  with, 
controllers  and  reflect  their  perceptions. 

To  maintain  a mental  picture  of  traffic  movement,  we  assume 
that  the  R controller  is  likely  to  look  at  an  aircraft's  data  display 
once  every  minute,  1 to  1.5  sec  per  look  being  sufficient  time  to  identify 
aircraft  and  recognize  or  recall  situations.  These  assumptions--! . 25  man- 
sec/look  and  1 look/aircraft-min--set  the  surveillance  workload  con- 
stant (c)  equal  to  1 25  man-sec/aircraft-min.  The  corresponding  surveil- 
lance workload  weighting  is  1.25  tg  man-sec/aircraft  (which  is  implicitly 
converted  to  man-min/aircraft  in  the  workload  model  equations). 


3.  Conflict  Processing  Work 

The  workload  times  for  processing  crossing,  merging,  and  over- 
taking conflicts  (k2N^,  k^N^,  and  k^N^)  represent  the  time  spent. 
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including  communications  and  decision  making,  to  maintain  separation 
assurance.  Aircraft  conflict  situations  arise  when  there  is  a prospec- 
tive violation  of  the  minimum  separation  allowable  between  aircraft. 
Because  prevention  of  such  situations  requires  corrective  action  in 
advance,  conflict  avoidance  by  the  controller  necessitates  a rather 
well-developed  capability  to  mentally  project  flight  trajectories  and 
to  perceive  potential  conflict.  The  R controller  activities  are  de- 
tection and  assessment,  then  resolution  and  coordination  of  potential 
conflicts. 


The  detection  and  assessment  task  entails  situation  recognition 
and  action  selection  based  on  traffic  data  derived  from  PVD  surveillance 
and  flight  strips;  the  resolution  is  the  issuance  and  negotiation  of  con- 
trol instructions  through  A/G  communication.  Effective  detection  and 
assessment  depend,  to  a large  extent,  on  judgment  and  familiarity  with 
procedures  developed  through  control  experience.  Observations  reveal 
that  journeymen  R controllers  have  refined  these  capabilities  to  such  a 
degree  that  situation  resolution  instructions  are  typically  issued  when 
conflicting  aircraft  first  enter  the  sector.  The  corrective  actions, 
which  usually  occur  five  or  so  minutes  before  violation  would  be  imminent, 
are  performed  as  soon  as  possible  to  avoid  possible  controller  distrac- 
tions by  other  critical  situations.  In  merging  situations,  some  inter- 
sector coordination  (usually  face-to-face  communication)  is  needed  to 
integrate  aircraft  sequencing  and  spacing. 


To  estimate  conflict  processing  workload  weightings,  we  use 
the  duration  of  each  conflict  processing  event  and  its  frequency  of 
occurrence ; 


k = t e 
3 mm 


where 

t , t , t , t are  the  minimum  performance  times  required  for 
crossing,  local  merging,  overtaking,  and  co- 
ordinated approach  merging  conflict  processing, 
measured  in  man-sec/conflict. 


28 


e , e , e , e are  conflict  event  frequency  factors  that 
cmoa  . . 

measure  the  rates  of  occurrence  of  crossing, 

local  merging,  overtaking,  and  coordinated 

approach  merging  conflict  events,  measured 

in  (conflicts/hr) / (aircraf t/hr) 2, 

We  determine  the  conflict  processing  time  (t^,  t^,  t^,  and  t^) 
by  estimating  and  summing  the  minimum  times  typically  needed  for  the 
detection  and  assessment,  resolution,  and  coordination  tasks.  These 
task  times  are  based  upon  field  observation  of  control  activity  and  sub- 
sequent interviews  of  controllers  using  the  videotape  playback  of  the 
observed  situation  to  review  controller  actions. 

The  hourly  conflict  frequency  factors  (e„,  e„,  e^,  and  e.,) 

determine  the  number  of  conflicts  per  hour  (e  N^,  e N^,  e and  e N*^) 

c’m  o a 

for  any  hourly  traffic  flow  rate,  N,  and  represent  the  total  number  of 
conflicts  that  may  be  occurring  at  one  or  more  conflict  points  in  the 
sector.  These  factors  are  calibrated  for  each  sector  using  mathematical 
models  (developed  by  SRI^"^)  that  determine  the  expected  frequency  of 
each  conflict  type  at  each  selected  location  or  along  each  selected 
route.  The  models  define  conflict  frequencies  as  functions  of  aircraft 
speeds,  route  intersection  angle,  route  lengths,  and  minimum  separation 
requirements.  These  relationships  are  formulated  as  a summation  of  the 
probability  of  pairwise  conflicts  between  aircraft;  the  models  are  further 
described  in  Appendix  A. 


C.  Sector  Capacity  Estimation 

The  R controller  workload  formulations  are  used  to  quantify  sector 
traffic  capacity.  We  estimated  sector  capacity  by  identifying  the  hourly 
traffic  rate  (ac/hr)  that  generates  48  man-min/hr  of  R controller  work. 
One  procedure  was  to  determine  R controller  workload  for  a range  of 
traffic  flow  rates,  and  search  for  the  flow  rate  corresponding  to  the 
workload  threshold.  The  R controller  workload  is  the  sum  of  routine, 
surveillance,  and  conflict  work  as  defined  by  the  workload  weighting 
parameters,  for  a specific  sector  operation.  We  calculated  workload  at 
successive  5 ac/hr  increments  in  traffic  flow,  and  obtained  the  sector 
traffic  capacity  by  interpolation. 


■o 
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V BAY  TRACON  OPERATIONS 


The  airspace  under  the  jurisdiction  of  Bay  TRACON  is  designated  as 
a Group  I Terminal  Control  Area  (TCA)  within  which  all  aircraft  are  con- 
trolled.  Bay  TRACON  provides  control  services  to  aircraft  arriving  and 
departing  three  major  civil,  two  military,  and  numerous  lesser  airports, 
as  well  as  enroute  aircraft  transiting  the  TCA.  Final  approach  and  re- 
lated airport  control  services  are  provided  by  separate  ATC  tower  facili- 
ties located  at  each  airport  and  coordinated  with  Bay  TRACON.^  Airspace 
above  that  of  Bay  TRACON  is  controlled  by  the  Oakland  ARTC  Center.  San 
Francisco  International  Airport  (SFO) , which  generates  mainly  air  carrier 
traffic,  is  the  primary  airport  and  is  included  in  the  TCA;  other  air- 
ports underlay  the  designated  TCA  airspace.  Two  major  civil  airports, 
Oakland  International  (OAK)  and  San  Jose  Municipal  (SJC) , also  generate 
commercial  traffic  but  with  significant  general  aviation  activity,  while 
the  Alameda  (NGZ)  and  Moffet  (NUQ)  Naval  Air  Stations  (NAS)  generate 
military  and  related  governmental  air  traffic.  The  remaining  airports 
under  the  TCA  generate  general  aviation  air  traffic,  with  some  commercial 
and  military  helicopter  activity. 

To  accommodate  the  complexity  of  traffic  patterns  required  by  the 
various  airports.  Bay  TRACON  is  configured  into  ten  sectors.  Six  of 
these  sectors,  AR-1,  AR-2,  AR-9,  AR-IO,  DR-1,  and  DR-2,  primarily  handle 
the  SFO  approach  and  departure  traffic  and  are  shown  in  the  Figure  1 


The  TCA  designation  requires  all  aircraft  operating  in  its  airspace  to 
be  subject  to  ATC  operating  rules  (thereby  eliminating  uncontrolled 
flights) , and  requires  equipment  and  pilot  to  meet  certain  qualifications. 
The  Group  I designation  currently  requires:  an  aircraft  to  be  equipped 
with  ATCRBS  and  'Mode  C transponders  (unless  it  is  a helicopter  or  an 
IFR  flight  not  to  or  from  the  primary  airport),  2-way  radio,  and  VOR  or 
TACAN  receiver;  the  take-off  or  landing  pilot  to  hold  at  least  a private 
pilot  certificate;  a large  turbine -powered  aircraft  to  operate  within 
designated  airspace  limits;  and  the  flight  to  be  ATC  authorized. 

Group  II  requirements  are  less  stringent.® 
t 

Bay  TRACON  is  located  on  the  property  of  Oakland  International  Airport, 
but  is  not  collocated  with  the  Oakland  Airport  Traffic  Control  Tower, 
nor  with  the  Oakland  Flight  Service  Station. 
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schematic;  two  sectors,  AR-3  and  AR-4,  handle  predominantly  OAK  and  NGZ 
traffic,  and  the  remaining  two  sectors,  DR-5  and  DR-6,  handle  predominantly 
SJC  and  NUQ  traffic.  Small  general  aviation  aircraft  operating  out  of 
other  airports  normally  remain  below  the  TCA  airspace  and  therefore  are 
not  controlled  by  Bay  TRACON. 

Figure  1 presents  the  West  Plan  sectorization  scheme  used  during 
the  predominant  wind  conditions.  An  alternative  Southeast  Plan  is 
generally  associated  with  weather  frontal  activity  in  the  Bay  Area,  and 
it  is  used  less  frequently.  The  West  Plan  sectors  are  structured  into 
a shelf-like  Inverted  conical  configuration  focused  on  SFO,  with  some 
sectors  overlaying  others  in  order  to  accommodate  the  typically  climbing 
or  descending  aircraft.* 

In  the  remainder  of  this  section,  we  first  describe  the  overall 
operational  integration  of  the  six  sectors  serving  SFO  traffic  under  the 
West  Plan  configuration.  This  plan  was  in  operation  during  the  period 
of  our  observation  and  data  collection  at  Bay  TRACON.  We  then  present 
more  detailed  descriptions  of  the  six  sector  operations. 

A.  Operational  Overview 

Aircraft  landing  at  SFO  are  handled  by  the  four  arrival  (AR)  sectors, 
which  also  handle  some  aircraft  destined  to  other  airports  (e.g. , OAK 
and  NGZ).  These  other  aircraft  are  on  approach  routes  (not  shown  in 
Figure  1)  that  diverge  from  or  cross  the  primary  SFO  arrival  routes. 
Aircraft  taking  off  from  SFO  are  handled  by  the  departure  (DR)  sectors; 
the  DR  sectors  also  handle  some  aircraft  from  other  airports,  which  are 
on  departure  routes  (not  shown  in  Figure  1)  merging  or  crossing  the  primary 
SFO  departure  routes. 

The  geographic  segregation  of  arrival  and  departure  traffic  exempli- 
fies the  procedural  separation  concept  whereby  preplanned  routes  (rather 
than  individual  aircraft  on  opposing  courses)  are  kept  apart.  At  those 
points  where  arrivals  and  departures  might  intersect  each  other,  pro- 
cedural separation  is  almost  always  applied  by  means  of  altitude  restric- 
tions which  tunnel  traffic  streams  around  others.  This  highly  structured 
system  of  separated  routings  is  effected  through  the  routine  use  of 
standard  instrument  departure  (SID)  and  arrival  (STAR)  assignments. 


* 

We  designate  the  routes  shown  in  Figure  1 as  "primary"  in  accordance 
with  our  field  observations  in  order  to  facilitate  the  textual  descrip- 
tions given  in  this  report;  this  designation  does  not  necessarily  con- 
form to  FAA  official  terminology. 
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The  following  discussions  of  arrival  and  departure  operations  per- 
tain to  the  primary  routings  shown  in  Figure  1.  We  will  subsequently 
present  more  detailed  descriptions  of  primary  and  secondary  route  inter- 
actions for  each  of  the  six  sectors. 


1 . Arrival  Operations 

Bay  TRACON  arrival  operations  are  based  on  the  "feeder  and 
final"  sectorization  concept,  but  with  the  final  sectors  sharing  juris- 
diction of  the  final  approach  corridor  to  parallel  runways.  Two  feeder 
sectors  (AR-9  and  AR-10)  set  up  traffic  to  be  processed  by  the  two  final 
sectors  (AR-1  and  AR-2) , and  the  two  final  sectors  fine-tune  the  traffic. 
AR-9  feeds  aircraft  to  AR-1,  and  AR-10  feeds  AR-2. 

The  integration  of  traffic  flows  from  a single  feeder  to  a 
single  final  (e.g. , AR-9  to  AR-1)  is  relatively  direct  and  a minimum  of 
intersector  coordination  is  usually  required.  The  feeder  sector  con- 
troller implements  the  sequencing  plan  by  issuing  clearances  to  the 
pilots,  while  the  final  sector  controller  generally  recognizes  the 
sequencing  plan  by  observing  on  his  radar  display  the  relative  positions 
and  speeds  of  incoming  aircraft.  Control  negotiations  between  feeder  and 
final  controller  regarding  individual  pairwise  mergings  are  not  routine. 

However,  integrating  traffic  from  the  different  feeders  (i.e., 
AR-9  and  AR-10)  for  merging  at  the  final  approaches  to  SFO  requires  a 
well  defined  procedural  control  structure  to  enable  both  feeders  to 
integrate  their  traffic  into  mutually  compatible  sequencings  and  spac- 
ings.  The  control  procedures  depend  on  whether  the  final  approach  is 
conducted  according  to  visual  or  instrument  approach  operations. 


a . Visual  Side-by-Side  Approach  Operations 

Final  approaches  to  SFO  are  primarily  for  landing  on 
either  runway  28R  or  28L,  which  are  shown  in  Figure  1.  Sector  AR-1 
controls  aircraft  on  the  final  approach  course  to  28L  and  Sector  AR-2 
controls  aircraft  on  the  parallel  approach  course  to  28R.  Under  visual 
conditions,  one  final  sector  controller  clears  aircraft  for  a visual 
approach  to  the  appropriate  runway  after  pilots  have  confirmed  visual 
sighting  of  the  airport  and  of  other  aircraft  in  the  vicinity;  control- 
lers continue  radar  surveillance  of  aircraft  on  the  final  approaches 
and  issue  advisories  as  necessary  to  facilitate  separation.  This  pro- 
cedure enables  aircraft  to  be  cleared  for  simultaneous  approaches  to 
the  two  parallel  runways,  resulting  in  side-by-side  approach  operations. 
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b. 


Instrument  In-Trail  Approach  Operations 


Although  both  28R  and  28L  are  equipped  with  instrument 
landing  systems  (ILS) , there  is  not  sufficient  lateral  separation  between 
the  two  runways  to  allow  simultaneous  side-by-side  instrument  approaches. 
Under  instrument  conditions,  minimum  in-trail  separations  are  maintained 
between  successive  aircraft  regardless  of  which  runway  approaches  are 
used.  That  is,  an  aircraft  on  the  28L  approach  course  is  kept  at  least 
3 n.m.  (more  for  wake  turbulence  spacing)  behind  a preceding  aircraft 
whether  the  latter  is  on  the  28R  or  28L  approach  courses.  In  essence, 
aircraft  on  both  parallel  approaches  are  treated  as  if  they  are  merged 
into  a single  stream  of  separated  traffic,  resulting  in  in-trail  approach 
operations. 


In-trail  approach  operations  require  coordination  between 
the  two  feeder  as  well  as  between  the  two  final  sectors'  controllers  to 
enable  sequencing  and  spacing  of  aircraft  on  the  final  approach.  In  this 
case,  the  two  feeder  controllers  (AR-9  and  AR-10)  need  to  integrate  their 
traffic  so  that  one  feeder's  aircraft  will  be  properly  sequenced  on  final 
approach  with  those  of  the  other,  rather  than  bringing  in  their  traffic 
independently  as  under  visual  conditions.  Using  radar  display  data,  a 
feeder  sector  controller  uses  speed  or  vectoring  controls  to  fit  his  air- 
craft into  holes  the  other  controller  has  built  into  his  traffic  stream. 
Otherwise,  the  two  feeder  sector  controllers  negotiate  the  pairwise  order- 
ing of  aircraft  and  decide  which  aircraft  will  be  first,  second,  and  so 
forth.  The  two  final  sector  controllers  must  similarly  use  radar  display 
data  to  be  aware  of  each  others'  traffic  in  order  to  maiiitain  spacings 
between  aircraft.  A final  sector  controller  must  keep  aircraft  under  his 
control  separated  from  each  other,  and  also  keep  his  aircraft  separated 
in-trail  from  parallel  aircraft  in  the  other  final  sector. 


2.  Departure  Operations 

As  shown  in  Figure  1,  departure  traffic  climbing  from  SFO  diverge 
into  various  routings.  The  primary  departure  runways  are  IL  and  IR,  from 
which  aircraft  climb  directly  into  Sector  DR-2  airspace  or  turn  left  into 
sector  DR-1  airspace.  Departures  are  also  conducted  off  runways  28R  and 
28L  and  these  are  handled  by  Sector  DR-1. 

The  airport  tower  hands  off  aircraft  directly  to  the  appropriate 
sector,  which  controls  the  climbing  aircraft  until  they  enter  enroute  air- 
space. Little  coordination  is  required  between  the  two  departure  sector 
controllers,  and  TRACON  control  procedures  for  departures  do  not  distin- 
guish between  visual  and  instrument  conditions. 
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B. 


Sector  Traffic  Operations 

We  wish  to  describe  the,  traffic  routing  geometries  specific  to  each 
of  the  six  sectors,  with  emphasis  on  the  potential  conflict  situations 
inherent  in  each.  For  descriptive  convenience,  we  first  address  arrival 
operations  for  visual  approaches  on  a sector-by-sector  basis;  secondly, 
the  effect  of  instrument  approaches  on  overall  arrival  operations;  and, 
thirdly,  departure  operations  on  a sector-by-sector  basis. 


1.  Arrival  Sectors--Visual  Approaches 

The  traffic  routing  and  potential  conflict  characteristics  for 
visual  approach  operations  at  the  two  feeder  and  two  final  sectors  are 
given  below. 

a . South  Feeder  (AR-9)  Sector 

Figure  2 depicts  the  major  air  routes  used  in  the  South 
Feeder  (AR-9)  Sector.  We  have  numbered  these  routes  separately  within 
each  sector  for  purposes  of  identification  and  description.  They  are 
used  as  follows: 

• Route  1 for  inbounds  to  SFO  from  Southern 
California. 

• Routes  2 and  3 for  inbounds  to  SFO  from  the 
Northwest  and  the  Pacific. 

As  indicated  in  the  figure,  most  of  the  traffic  on  Route  1 enters  the 
sector  from  the  Oakland  ARTCC  descending  to  or  level  at  10,000  ft  and 
leaves  the  sector  descending  to  or  level  at  6,000  ft.  On  Route  2,  most 
of  the  traffic  enters  descending  to  or  level  at  11,000  ft  and  leaves 
the  sector  descending  to  or  level  at  6,000  ft;  while  most  traffic  on 
Route  3 enters  descending  to  or  level  at  6,000  ft  and  leaves  at  5,000  ft. 

Since  all  of  the  aircraft  are  landing  at  SFO,  they  must  be  locally  merged 
by  the  South  Feeder  controller  before  handoff  to  the  Woodside  Final  sector. 

Although  the  air  routes  actually  merge  in  Woodside  Final  airspace,  as 
indicated  in  Figure  2 by  the  two  circles  where  the  dashed  route  lines 
converge,  the  sequencing  and  spacing,  merging,  and  resolution  of  any 
potential  conflicts  at  these  points  are  performed  by  the  South  Feeder 
controller.  There  are  potential  overtake  conflicts  on  nearly  all  of 

the  route  segments.  • 
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FIGURE  2 SOUTH  FEEDER  (AR-1)  ROUTES 

b.  North  Feeder  (AR-10)  Sector 

Figure  3 shows  the  major  air  routes  used  in  the  North 
Feeder  (AR-10)  Sector.  Again,  we  designate  the  routes  by  number  as 
follows : 


• Route  1 for  inbounds  to  SFO  from  the  South 
and  East. 

• Route  2 for  inbounds  to  SFO  from  the  North 
and  East. 

• Route  3 for  inbounds  to  OAK  and  Alameda  NAS 
from  the  Southeast. 
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FIGURE  3 NORTH  FEEDER  (AR-2)  ROUTES 

As  indicated  in  Figure  3,  most  of  the  traffic  on  Route  1 enters  the  sec- 
tor at  or  descending  to  11,000  ft  and  leaves  the  sector  at  or  descending 
to  7,000  ft.  On  Route  2,  most  of  the  traffic  enters  the  sector  at  or 
descending  to  10,000  ft  and  leaves  the  sector  at  or  descending  to 
7,000  ft.  For  Route  3,  the  traffic  usually  remains  level  at  7,000  ft 
through  the  sector.  The  traffic  on  Routes  1 and  2 are  landing  at  SFO; 
hence,  these  aircraft  must  be  locally  merged  by  the  North  Feeder  con- 
troller before  handoff  to  the  Foster  Final  (AR-6)  sector.  Also,  as 
indicated  by  the  cross-hatched  area,  there  is  a potential  conflict  zone 
where  all  three  routes  come  together,  and  resolution  of  any  potential 
conflicts  at  this  point  must  be  performed  by  the  North  Feeder  controller 
before  transferring  control  of  the  aircraft  to  adjacent  sectors.  Our 
observations  indicated  that  traffic  on  Route  3 inbound  to  Oakland  and 
Alameda  NAS  tended  to  be  procedurally  separated  by  altitude  from  the 
inbound  SFO  streams,  with  Route  3 traffic  crossing  Cedar  Ridge  on  the 
average  of  2,000  to  3,000  ft  lower  than  the  10,000  to  12,000  ft  altitudes 
at  which  Route  1 and  2 traffic  crosses  this  area.  We  do  not  show  several 
minor  routes  through  the  sector  which  are  primarily  used  by  aircraft 
flying  to  and  from  the  San  Jose  and  Sacramento  areas.  Their  contribu- 
tion to  controller  conflict  processing  activities  is  usually  negligible 
due  to  light  traffic  volumes  and  the  routine  altitude  separation  at 
route  crossings.  When  potential  crossing  conflicts  do  occur  between 
these  aircraft  and  the  high  volume  inbound  streams,  climbing  directives 
are  issued  to  the  aircraft  crossing  the  inbound  corridor. 

The  sequence  and  space  maintenance  activities  associated 
with  aircraft  on  the  major  inbound  routes  through  both  feeder  sectors 
involves  a significant  amount  of  overtake  conflict  processing.  For 
aircraft  transitions  into  SFO  and  OAK,  controllers  will  generally  allow 
the  use  of  pilot  discretion  in  descending  through  the  feeder  sectors  to 
7,000  ft  and  slowing  to  250  knots.  The  resulting,  unique  deceleration 
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and  descent  profiles  of  each  inbound  aircraft  are  characteristic  of 
feeder  sector  operations  and  contribute  greatly  to  the  overtaking  work- 
loads of  these  sectors. 


c.  Woodside  Final  (AR-1)  Sector 


sector. 


Figure  4 shows  the  tnajor  routes  used  in  the  Woodside  Final 
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FIGURE  4 WOODSIDE  FINAL  (AR-9)  ROUTES 


Although  the  routes  designated  as  1 and  2 in  the  figure 
are  physically  separate,  they  are  considered  by  the  Woodside  Final 
controller  as  one  flow  by  the  time  they  enter  the  sector.  Preliminary 
sequencing  and  spacing  of  the  merging  traffic  on  the  two  routes  has  been 
performed  by  the  South  Feeder  controller  before  handing  over  the  aircraft 
to  the  Woodside  Sector;  the  Woodside  Final  controller  fine  tunes  the  in- 
bound streams  so  that  the  sequence  established  upstream  is  maintained  at 
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the  appropriate  in-trail  separation,  which  will  be  three,  four,  five, 
or  six  miles  in  trail,  depending  on  the  size  and  types  of  the  aircraft 
involved.  The  Woodside  controller  also  makes  adjustments  of  speeds  and 
altitudes  in  order  to  prepare  aircraft  for  handoff  to  tower  on  final 
approach . 


Aircraft  enter  the  sector  on  Route  1 from  the  South  be- 
tween 9,000  and  10,000  ft  and  descend  to  approximately  5,000  ft  and 
250  kts  at  the  Menlo  fix.  Aircraft  from  the  North  and  West  enter  near 
OSI  at  about  6,000  ft  and  reach  Menlo  at  3,000  to  4,000  ft  and  250  kts. 
All  inbound  aircraft  are  handed  off  to  the  SFO  tower  at  2,000  to  3,000  ft 
and  200  to  250  kts  at  the  localizer  outer  marker  (LOM)  about  5 miles 
from  the  runway  19  complex. 

During  periods  of  light-to-moderate  traffic  and  relatively 
good  weather,  the  so-called  "Gas  Can"  route  to  SFO  is  used  by  aircraft 
inbound  from  the  North  and  West  to  conserve  fuel.  These  aircraft  enter 
the  Woodside  Sector  at  about  10,000  ft  directly  over  the  SFO  VOR  and  make 
a "teardrop"  approach  trajectory  to  intercept  the  final  approach  path  at 
the  LOM  at  2,000  to  3,000  ft.  Although  a few  such  approaches  were  ob- 
served during  the  hour  of  data  collection  at  the  sector,  the  prescribed 
approach  for  these  aircraft  during  heavy  traffic  involves  flying  from 
the  Point  Reyes  VOR  (RYE)  to  HMB  and  merging  with  Route  2 at  OSI. 

Virtually  all  the  traffic  observed  at  Woodside  was  inbound 
to  SFO,  although  it  is  possible  that  general  aviation  traffic  entering 
the  TCA  from  satellite  airports  could  conflict  with  "Gas  Can"  and  Final 
approach  traffic  and  that  inbound  military  traffic  at  Moffett  Field  could 
generate  potential  crossing  conflicts  with  Route  1 traffic  over  the 
Boulder  Creek-Saratoga  areas.  We  assume  that  the  Mof fett-Route  1 cross- 
ings are  procedurally  separated  by  altitude  and  the  general  aviation  con- 
flicts to  be  negligible. 


d . Foster  Final  (AR-2)  Sector 

The  primary  purpose  of  the  Foster  City  Sector  controller 
is  to  ensure  the  proper  in-trail  separation  and  to  maintain  the  arrival 
sequence  of  aircraft  on  the  inbound  arrival  stream  coming  to  SFO  from 
the  east  through  the  North  Feeder  Sector.  Most  aircraft  follow  Route  1, 
entering  the  sector  west  of  the  Cedar  Ridge  fix,  descending  through 
7,000  ft,  and  are  radar  vectored  to  the  SFO  localizer,  reaching  the  LOM 
at  altitudes  between  2,000  to  3,000  ft  where  they  are  handed  off  to  the 
tower.  Route  2 carries  some  low  speed,  general  aviation  or  commuter 
traffic  which  is  inbound  to  SFO  over  the  Oakland  and  Hayward  areas;  this 
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route  merges  with  the  primary  inbound  stream  at  the  LOM.  Additionally, 
an  occasional  "Gas  Can"  arrival  over  SFO  from  the  Northwest  transitioning 
through  the  South  Feeder  Sector  will  be  turned  over  the  Bay  and  handled 
by  the  Foster  controller  as  either  a noise  abatement  procedure  or  as  an 
attempt  to  balance  traffic  workload  between  final  sectors.  Separation 
standards  are  the  same  as  those  used  by  Woodside  controllers.  Figure  5 
depicts  the  route  structure  observed  in  the  Foster  Final  Sector. 
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FIGURE  5 FOSTER  FINAL  (AR-10)  ROUTES 


Under  visual  conditions,  when  simultaneous  landings  on 
the  28  runway  complex  at  SFO  are  performed,  we  have  assumed  that  the  two 
feeder/final  pairs.  South  Feeder/Menlo  Final  and  North  Feeder/Foster 
Final  are  operationally  independent,  with  Foster  City  traffic  using  Run- 
way 28  and  Woodside  traffic  using  28L.  It  follows,  therefore,  that  poten- 
tial merge  conflicts  in  the  localizer  area  will  be  negligible  and  that 
both  final  approach  controllers  will  be  engaged  chiefly  in  the  processing 
of  overtaking  conflicts. 


2.  Instrument  Approach  Characteristics 

When  instrument  landings  are  necessary,  side-by-side  approaches 
cannot  be  performed  and  aircraft  must  be  spaced  in  trail  for  landings  on 
either  of  the  parallel  runways,  28R  or  28L.  Figure  6 shows  the  two  poten- 
tial merge  conflict  points  in  the  localizer  area.  (We  have  assigned  all 
"Gas  Can"  traffic  to  the  standard  arrival  route  from  the  northwest  over 
OSI.) 


Merge  Point  One  is  the  most  critical  potential  conflict  zone, 
since  it  combines  Woodside  Route  1 and  2 traffic  with  Foster  City 
Route  1 traffic;  these  routes  contain  virtually  all  the  commercial  and 
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FIGURE  6 POTENTIAL  INTRUMENT  APPROACH  MERGE  CONFLICT  POINTS 


private  jet  arrivals  into  SFO.  Merge  Point  Two  merges  the  largely  gen- 
eral aviation  traffic  on  Foster  City  Route  2 (see  Figure  5)  with  the 
traffic  combined  at  Merge  Point  One. 

As  mentioned  previously,  the  merging  activities  of  the  Foster 
and  Woodsidc  Final  controllers  are  negligible  during  visual  conditions. 
However,  during  instrument  operations,  merging  operations  at  Merge  Points 
One  and  Two  must  be  coordinated  by  the  feeder  sectors,  to  ensure  the 
proper  alternate  in-trail  spacing  of  aircraft  within  the  approach  routes. 
These  coordinated  mergings  are  in  addition  to  the  local  mergings  per- 
formed by  each  sector  during  both  visual  and  instrument  conditions.  Also, 
the  necessity  of  mutually  sequencing  traffic  from  both  feeder  and  final 
pairs  implies  a necessity  for  each  sector  to  selectively  increase  in-trail 
spacings;  this  in  turn  increases  overtaking  conflict  work. 


3.  Departure  Sectors 

The  traffic  routing  and  potential  conflict  characteristics  of 
the  two  departure  sectors  are  given  below. 


a.  Sutro  Departure  (DR-1)  Sector 

Figure  7 shows  the  major  departure  and  crossing  routes 
used  in  the  Sutro  Departure  Sector. 
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FIGURE  7 SUTRO  DEPARTURE  (DR-11  ROUTES 


These  routes  are  used  as  follows; 

• Route  1,  the  most  heavily  used  flight  path  in 
the  sector,  for  departures  from  SFO  to  the 
west,  south,  and  southeast. 

- Route  la  for  departures  to  the  south  and  west 
from  OAK,  that  merge  in  trail,  but  are  altitude 
separated  from  SFO  departures. 

- Route  lb,  for  oceanic  departures  separating 
from  the  main  body  of  Route  1 traffic. 

• Route  2,  for  departures  from  Moffett  Field  and 
San  Jose  area  airports  to  the  Northwest  toward 
Point  Reyes. 

• Route  3,  primarily  for  general  aviation  and 
commuter  aircraft  arriving  at  SFO  (STOL  air, 

SFO  helicopters)  and  Peninsula  airports;  and 
Route  3a,  for  general  aviation  and  commuter 
aircraft  departing  SFO  to  the  west  and  turning 
sharply  to  the  southeast. 

Aircraft  on  departure  routes  1 and  lb  generally  enter  the 
sector  at  or  climbing  to  2,000  ft  at  about  250  kts,  and  they  are  handed 
off  to  the  Oakland  ARTC  Center  at  or  climbing  to  altitudes  between 
7,000  and  10,000  ft  and  with  airspeeds  near  300  kts  for  commercial  jet 
aircraft.  Route  1 aircraft  climb  rapidly  and  are  therefore  above  many 
other  aircraft  in  the  sector  at  points  where  their  routes  intersect, 
thereby  minimizing  the  potential  for  crossing  conflicts.  Route  1 crossing 
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conflicts  can,  however,  occur  with  some  of  the  military  aircraft  on 
Route  2,  and  with  most  of  the  aircraft  on  Route  3 that  intersect  Route  1 
departures  from  the  Runway  28  complex  at  SFO.  Merging  conflicts  are, 
of  course,  possible  on  Routes  1 and  3,  while  potential  overtakes  exist 
primarily  on  Route  1. 


b.  Richmond  Departure  (AR-2)  Sector 

Figure  8 shows  the  major  departure  and  crossing  routes  used 
in  the  Richmond  Departure  Sector.  These  routes  are  designated  and  used  as 
follows : 


• Route  1 for  all  departures  to  the  north  and  east 
via  the  OAK  VOR,  where  it  branches  into  three 
branches.  They  are: 

- Route  la,  an  aggregation  of  routes  with  regional 
destinations  such  as  Stockton  and  Fresno,  and 
nationwide  destinations  east  of  Sacramento  and 
Reno. 

- Route  lb  for  traffic  to  the  Sacramento  area  and 
points  north  and  east. 

- Route  Ic,  toward  Napa  for  departures  to  Portland, 
Seattle,  and  other  points  to  the  north  and  west. 

• Routes  2a,  2b,  and  2c  for  departures  from  OAK  and 
NAS  Alameda  to  the  west,  east,  and  north,  respec- 
tively. 

• Route  3,  representing  an  aggregation  of  radar  vector 
routes  involving  general  aviation  and  commercial 
commuter  aircraft  flying  through  the  TCA  from  the 
Sausalito  area  toward  OAK  and  beyond. 

• Route  4,  similar  in  structure  and  aircraft  mix  to 
Route  3,  but  lying  in  a more  northerly  and  southerly 
heading. 

Nearly  all  the  departing  aircraft  on  these  routes  enter  the  sector  at  or 
climbing  to  2,000  ft  and  are  handed  off  to  Oakland  ARTC  Center  at  or 
climbing  to  altitudes  between  5,000  and  10,000  ft;  the  lower  performance 
aircraft  in  the  sector  airspace  tend  to  fly  at  or  below  5,000  ft.  Poten- 
tial crossing  conflicts  between  low  level  enroute  aircraft  and  fast 
climbing  departures  out  of  SFO  and  OAK  are  minimized  by  routine  altitude 
separation.  Some  crossing  conflict  processing  appears  necessary  to 
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separate  random  pairs  of  low  level  and  enroute  aircraft  on  Routes  3 and 
h,  while  potential  overtakes  exist  on  each  of  the  SFO  and  OAK  departure 
routes. 
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FIGURE  8 RICHMOND  DEPARTURE  (DR-2)  ROUTES 
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VI  BAY  TRACON  ARTS  111  MODEL 


SRI  conducted  field  observations  at  Bay  TRACON  during  the  week  of 
March  29,  1976.  We  collected  operations  data  for  the  six  sectors  con- 
trolling SFO  arrival  and  departure  aircraft;  these  include  two  final 
sectors  (AR-1  and  AR-2),  two  feeder  sectors  (AR-9  and  AR-10)  and  two 
departure  sectors  (DR-1  and  DR-2) . Data  from  one  session  at  each  of  the 
six  sectors  was  reduced  to  obtain  the  information  necessary  to  model  R 
Controller  routine,  surveillance,  and  potential  conflict  processing  work- 
load for  the  1-man,  1.5-man,  2-man,  and  2.5-man  sector  team  manning  re- 
gimes corresponding  to  current  ARTS  111  operations. 


A.  Routine  Work 


Our  R controller  model  requires  estimation  of  routine  workload 
weighting  (k]^)  using  the  routine  event  frequencies  and  task  performance 
times  measured  from  field  data  collection  and  reduction.  In  the  following 
paragraphs,  we  present  the  results  of  our  data  measurements  and  workload 
weighting  calculations. 


1 . Routine  Event  Frequencies 


Our  measurements  of  routine  event  frequencies  (r^^j's)  are  sum- 
marized in  Table  1 for  the  six  Bay  TRACON  sectors.  Each  frequency  value 
is  the  ratio  of  the  total  number  of  routine  events  observed  during  one 
hour  to  the  total  number  of  aircraft  generating  those  events;  therefore, 
each  frequency  value  is  an  empirically  derived  representation  of  the  ex- 
pected rate  of  event  occurrence  associated  with  each  aircraft. 


We  distinguish  the  routine  events  in  Table  1 according  to  basic 
and  supplemental  events;  supplemental  events  are  indented  in  the  table's 
listing  of  event  descriptions.  The  basic  events  are  "parent"  events, 
each  of  which  may  have  one  or  more  supplemental  events  associated  with 
it.  A supplemental  event  will  occur  as  frequently  or  less  frequently 
than  its  parent  basic  event,  but  never  more  frequently.  This  phenomena 
is  due  to  the  nature  of  the  task  structure  which  we  use  to  define  each 
event;  this  structure  will  be  explained  in  the  discussion  of  event  per- 
formance times  which  follows. 
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The  event  frequencies  are  a convenient  means  to  distinguish  the 
routine  work  characteristics  of  different  sectors.  This  property  is 
demonstrated  in  Table  1 by  the  differences  between  sectors  in  the  fre- 
quencies measured  for  all  but  a few  of  the  individual  events.  For  ex- 
ample, the  frequency  of  an  "altitude  instruction"  event  (included  as  part 
of  the  "traffic  structuring"  function)  differs  from  one  sector  to  the 
other.  Also,  some  events,  including  basic  events,  may  be  performed  by  some 
sector  teams  but  not  by  others,  as  evidenced  by  the  "handoff-initiation- 
silent  event. 


2.  Routine  Event  Performance  Times 


We  identified  the  task  components  of  each  event  as  summarized 
in  Table  2.  The  individual  task  performance  times  (ij's)  shown  in  Table  2 
are  stopwatch  measurements  of  observed  minimum  execution  times;  these  rep- 
resent work  requirements  during  capacity  traffic  conditions,  when  control- 
lers are  assumed  to  be  operating  at  peak  efficiency. 

During  our  observation  sessions,  each  of  the  four  arrival  sectors 
was  operating  under  visual  approach  conditions  as  a 1-man  team  (R  control- 
ler only),  while  both  departure  sectors  were  operating  as  1.5-man  teams 
(one  R controller  for  each  sector,  sharing  a coordinator  between  them) . 

By  carefully  cross-referencing  the  various  data  collection  sources  (i.e., 
communications  recordings,  flight  strips  or  paper  scratch  pads,  and  man- 
ual observation  records),  .we  were  able  to  extrapolate  the  tasks  necessary 
to  carry  out  each  event  regardless  of  which  controller  is  performing  them, 
and  whether  the  operations  occur  under  visual  or  instrument  conditions. 

The  resulting  task  items  in  Table  2 therefore  represent  the  requirements 
of  a "composite  team,"  and  do  not  describe  the  specific  R controller  task 
requirements  for  either  of  the  1-man,  1.5-man,  2-man,  or  2.5-man  team 
regimes . 


We  will  subsequently  use  the  composite  team  tasks  structure  of 
Table  2 to  allocate  specific  tasks  to  the  R controller  for  each  of  the 
four  regimes.  We  observed  that  the  minimum  task  performance  times  did 
not  vary  between  sectors,  and  the  composite  team  task  times  of  Table  2 
thus  apply  to  each  of  the  six  sectors.  The  data  regarding  task  times 
are  used  to  distinguish  the  work  time  requirements  of  events  under  the 
alternative  team  manning  regimes;  moreover,  task  time  data  are  also  used 
in  conjunction  with  event  frequency  data  to  develop  work  requirements  for 
each  individual  sector.  Before  describing  the  R controller  requirements 
for  each  regime,  we  will  examine  the  underlying  task  structure  for  the 
composite  team. 
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Table  2 
COKPOSITE  TEAM 

ROL’TIN’E  EVENT  MINIMVM  PERFORMANCE  TIME  ESTIM/\TES 
OAKLAND  BAY  TRACON,  SYSTEM  1— ARTS  III  BASE 


Routine  Control  Event  Description 


Event  Basic  Event  and 

Function  Supplenental  Event 

Control  Kandoff  acceptance 

jurisdiction  Manual  acceptance-silent 
transfer  Tover  departure  call 

Controller  coordination 

Handof f initiation- si lent 
Controller  coordination 


i Peifornance  Time  by  Task  (oan-sec/event) 

A/G  Coa-  [oara  Flight  Inter phone 'f^ce-to- 

tnunica-  | Entry/  Strip  i Cofflmunica- , Face  Com- 
tlon  Process-  jcunicatlon 

; Operar  io^  ing*  [ ! 


Traffic 

structuring 


Initial  pilot  call-in 
TCA  clearance  request 

Initial  controller  response 
Altitude  instruction 
Data  update 

Hcading/route  Instruction 
Speed  instruction 
Approach/runway  advisory 
PIT)  display  update 
Traffic  advisory 
ATIS  advisory 
Altimeter  setting  advisory 
Transponder  code  assignment 
Controller  coordination 

Altitude  instruction 
Data  update 

Controller  coordination 

Heading/route  instruction 
Controller  coordination 

Speed  instruction 

Approach  clearance 

Runway  assignment 

Traffic  advisory 

Pilot  altitude  report 

Pilot  heading/position  report 

Pilot  speed  report 

Miscellaneous  A/G  comounicatlon 

Frequency  change 

Transponder  code  change 
Approach/runway  advisory 


Altitude  revision 

Controller  coordination 

Route/heading  revision 
Controller  coordination 

Miscellaneous  pilot  request 


Flight  strip  processing  Includes  paper  scrntch-pad  processing. 
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a . Composite  Team  Routine  Tasks 

Table  2 identifies  the  tasks  associated  with  the  basic  and 
supplemental  events  first  presented  in  Table  1.  Each  basic  event  is  com- 
prised of  a parent  set  of  tasks  necessary  for  event  execution;  each  sup- 
plemental event  is  associated  with  an  additional  set  of  tasks  that  are 
performed  only  when  required. 

Control  Jurisdiction  Transfer--Under  the  control  jurisdic- 
tion transfer  function,  the  basic  handoff  acceptance  event  requires  2 man- 
sec  of  flight  strip  processing  or  paper  scratch  pad  processing  (which  is 
included  under  the  "flight’  strip  processing"  task  category  in  Table  2) . 

In  this  case,  the  flight  strip  processing  is  performed  by  the  feeder  and 
departure  sector  teams  who  arrange  or  distribute  the  strips,  or  scratch 
pad  processing  is  performed  by  the  final  sector  teams  who  handwrite  the 
aircraft's  flight  identity  onto  the  scratch  pad.  These  actions  are  con- 
sidered basic  tasks  since  they  are  performed  whenever  a handoff  acceptance 
occurs.  In  contrast,  the  supplemental  events  associated  with  handoff  ac- 
ceptance are  not  always  performed.  For  instance,  the  feeder  and  final 
sectors  manually  accept  (silently,  without  interphone  contact)  handoffs 
from  other  sectors  by  means  of  a 2 man-sec  keyboard  data  entry/display 
operation;  this  operation  increases  the  total  handoff  acceptance  time  to 
4 man-sec.  The  departure  sectors  need  not  perform  this  supplemental  oper- 
ation for  climbing  aircraft  whose  tracks  are  automatically  acquired  by 
the  ARTS  III  system.  However,  departure  sector  teams  receive  interphone 
calls  from  towers,  e.g.,  SFO  ATCT) , advising  of  each  aircraft  take-off. 

This  supplemental  event  (tower  departure  call)  takes  2 man-sec  and  enables 
the  TRACON  controllers  to  initiate  flight-strip  handling  and  confirm  that 
each  aircraft  is  correctly  acquired,  tracked,  and  displayed  on  the  PVD. 
Another  supplemental  event,  controller  coordination,  may  accompany  a hand- 
off acceptance  and  typically  requires  a 6 man-sec  interphone  communication 
between  different  sector  teams  and  a 3 man-sec  face-to-face  message  relay 
(voice  or  hand-signal)  or  consultation  between  controllers  within  a sector. 

A basic  handoff  initiation  event  is  performed  silently,  re- 
quiring a 3 man-sec  manual  data  entry/display  operation,  and  it  may  be 
accompanied  by  supplemental  controller  coordination.  Since  the  tracks  of 
aircraft  descending  to  airports  are  automatically  dropped  by  the  ARTS  III 
system,  final  sectors  need  not  initiate  handoffs  to  towers  for  aircraft 
on  final  approach.  This  operational  characteristic  of  the  final  sector 
does  not  alter  the  task  requirements  of  the  basic  handoff  initiation  event 
in  Table  2 but  is  represented  under  the  event  frequency  tabulations  of 
Table  1 (where  handoff  initiation  events  are  shown  not  to  occur  in  the 
final  sectors) . 
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This  rather  detailed  discussion  of  handoff  events  is  in- 
tended to  demonstrate  the  application  of  the  basic  and  supplemental  event 
concepts  and  the  relationships  between  event  frequencies  and  performance 
times.  These  concepts  apply  to  the  models  of  the  remaining  routine  events, 
which  we  now  briefly  describe. 

Traffic  Structuring  and  Pilot  Requests--All  basic  events 
under  structuring  and  pilot  request  are  initiated  by  an  A/G  communication 
and  sometimes  Include  flight  strip  marking.  The  performance  time  of  each 
A/G  communication  task,  which  entails  negotiation  and  confirmation  between 
pilot  and  controller,  is  measured  from  the  beginning  transmission  to  the 
ending  transmission  for  both  parties  and  includes  time  devoted  to  decision 
making.  Similarly,  interphone  and  face-to-face  communication  includes 
both  decision-making  and  transmission  time. 

The  first  traffic  structuring  event  for  an  aircraft  is  the 
pilots  initial  flight  identity  and  altitude  call-in  on  the  sector's  A/G 
radio  frequency,  taking  4 man-sec.  The  occurrence  of  the  call-in  is 
manually  "checked"  on  the  paper  scratch  pad  or  flight  strip  (or  at  least 
generates  flight  strip  review  or  rearrangement),  requiring  1 man-sec.  In 
a few  cases,  an  unexpected  aircraft  "pop-up"  involving  a pilot's  request 
to  enter  the  TCA  requires  an  additional  4 man-sec  for  the  A/G  radio  call-in. 
Such  a supplemental  TCA  clearance  request  also  causes  the  controller  to 
spend  10  man-sec  to  hand  write  a new  flight  strip,  and  6 man-sec  to  enter 
the  appropriate  flight  and  tracking  data  by  means  of  keyboard  data  entry/ 
display  operations.  The  controller's  initial  response  to  the  pilot  takes 
2 man-sec  of  A/G  communications  to  acknowledge  the  call-in  and  is  followed 
by  one  or  more  supplemental  events.  Such  events  typically  are  part  of  a 
single  lengthy  A/G  communication  used  to  issue  altitude,  heading  or  speed 
clearances;  approach  and  runway,  traffic,  ATIS,  and  altimeter  setting 
advisories;  or  transponder  code  assignments.  Each  one  of  these  A/G  mes- 
sages takes  an  additional  3 man-sec  and  may  require  other  tasks.  For 
example,  data  entry /display  operations  taking  3 man-sec  are  used  to  enter 
expected  runway  assignment  data  for  PVD  display  or  to  request  or  enter  a 
transponder  discrete  code  assignment.  Flight  strip  processing  tasks  taking 
2 man-sec  may  be  needed  to  hand  write  altitude  or  transponder  code  revis- 
ions. Also,  occasional  controller  coordination  of  the  pilot  call-in  re- 
quires 5 man-sec  and  3 man-sec,  respectively,  for  interphone  or  face-to- 
face  communications. 

These  controller-to-pilot  traffic  structuring  events  may 
be  performed,  revised,  or  repeated  at  some  time  after  the  initial  pilot 
call-in,  in  which  case  they  may  require  5 to  6 man-sec  of  A/G  communica- 
tions, depending  on  the  transaction.  Other  A/G  coninunications  involving 
pilot  reports  and  requests  regarding  altitude,  position,  or  speed,  and 
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other  miscellaneous  messages  (such  as  weather  reports)  are  performed  as 
needed . 


A 4 man-sec  controller-to-pilot  instruction  to  change  ra- 
dio frequency  to  that  of  the  next  sector  or  tower  culminates  the  traffic 
structuring  and  pilot  request  activity  for  an  aircraft.  It  is  manually 
recorded  by  crossing-out  the  aircraft  flight  identity  on  a paper  scratch 
pad  or  filing  the  flight  strip;  each  such  task  requires  1 man-sec.  In 
addition,  a 2 man-sec  transponder  code  change  (normally  to  establish  a 
VFR  non-discrete  code)  or  a 3 man-sec  approach /runway  advisory  may  be 
issued  to  supplement  the  basic  frequency  change  A/G  communication. 

General  Intersector  Coordination--These  events  include 
informational  transfers  performed  by  controllers  to  maintain  mutual  cog- 
nizance of  multisector  traffic  movement  and  are  not  part  of  handoff, 
traffic  structuring,  or  pilot  request  functions.  Pointout  actions  are 
required  by  a sector  team  to  retain  control  of  aircraft  briefly  in  or  near 
another  sector's  airspace.  Both  pointout  acceptance  and  initiation  typi- 
cally require  6 man-sec  of  interphone  communication  between  different 
sector  teams  to  coordinate  and  effect  the  operation,  and  3 man-sec  of 
face-to-face  communication  between  members  of  a sector  team.  The  point- 
out acceptance  operation  also  involves  a 3 man-sec  keyboard  data  entry/ 
display  operation  to  force  the  aircraft's  data  block  on  to  the  receiving 
sector  team's  PVD  display. 

The  remaining  general  intersector  coordination  events  in- 
volve 5 man-sec  interphone  and  3 man-sec  face-to-face  communications. 
Control  instruction  approvals  are  issued  in  response  to  other  sector 
team's  traffic  structuring  and  pilot  request  activities.  Planning  ad- 
visories are  used  to  negotiate  or  transmit  procedural  requirements,  while 
aircraft  status  advisories  clarify  individual  aircraft  situations  and  do 
not  necessitate  intrasector  face-to-face  communications. 

General  System  Operation--This  category  includes  those 
activities  not  mentioned  in  the  above  descriptions,  such  as  data  block 
forcing  removal  and  PVD  display  adjustment.  General  system  operation 
events  are  performed  entirely  by  3 man-sec  data  entry/display  operations 
and  are  needed  for  minute-by-minute  PVD  display  maintenance. 


b.  R Controller  Routine  Tasks 


We  now  assign  the  composite  team  task  requirements  specific 
to  the  R controller  under  each  of  the  four  sector  team  manning  regimes. 
These  allocations  are  made  in  accordance  with  the  operational  assumptions 
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given  in  a previous  section  of  this  report  regarding  sector  control  re- 
sponsibilities under  the  ARTS  III  system,  and  they  are  summarized  in  Ta- 
bles 3,  4,  5,  and  6 for  the  1-man,  1.5-man,  2-man,  and  2.5-man  teams, 
respectively 

1-man  2feam--Under  the  1-man  team  shown  in  Table  3,  the  R 
controller  is  assigned  all  the  tasks  necessary  for  event  execution  except 
face-to-face  communication;  this  is  not  performed  since  there  is  no  other 
team  member  to  communicate  with.  The  Table  3 task  time  entries  corre- 
spond to  the  Table  1 composite  team  entries,  excluding  the  face-to-face 
tasks.  The  resulting  minimum  time  required  to  execute  each  event  is 
obtained  by  summing  the  component  task  times,  as  shown  in  the  right-hand 
column  of  Table  3. 

1.5-man  Team- -We  assume  that  the  addition  of  a coordinator 
supporting  a pair  of  sectors  enables  each  R controller  to  assign  inter- 
phone communications  tasks  to  the  coordinator.  However,  an  R controller 
must  be  kept  advised  of  the  intersector  negotiations  being  conducted  by 
the  coordinator,  and  face-to-face  communications  between  R controller 
and  coordinator  are  necessary.  The  resulting  R controller  task  require- 
ments for  the  1.5-man  team  are  summarized  in  Table  4;  these  requirements 
were  obtained  by  eliminating  the  interphone  communication  tasks  from  the 
1-man  team  operation  in  Table  3,  and  introducing  face-to-face  communica- 
tions tasks,  from  the  composite  team  tasks  in  Table  2. 

The  coordinator  also  participates  in  handoff  activities  by 
distributing  flight  strips  to  the  appropriate  R controller  and  (according 
to  our  observations)  performing  half  the  manual  keyboard  silent  handoff 
acceptance  and  initiation  events.  Therefore,  we  eliminate  from  the  R 
controller  requirements  the  handoff  acceptance  flight  strip  processing 
task  as  shown  in  Table  4.  The  coordinator's  contribution  to  handoff  re- 
quirements is  signified  by  reducing  by  one-half  the  frequency  of  silent 
manual  acceptance  and  silent  handoff  initiation  events  presented  in  Ta- 
ble 1.  This  adjustment  to  the  handoff  event  frequencies  applies  only  to 
the  1.5-man  team  regime. 


2-man  Team--The  R and  H controllers  share  task  responsi- 
bilities for  a single  sector,  and  no  coordinator  position  is  manned.  In 
this  case,  we  assume  the  R controller  assigns  the  H controller  all  inter- 
phone communication  tasks,  some  of  the  keyboard  data  entry/display  opera- 
tion tasks,  and  flight-strip  processing  (or  paper  scratch  pad)  processing 
tasks  required  for  handoffs.  This  reallocation  of  responsibilities  re- 
sults in  the  set  of  R controller  tasks  shown  in  Table  5.  These  task  time 
entries  are  obtained  from  Table  3 by  eliminating  those  entries  relating 
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Table  3 


fraffic  Initial  pilot  call-in 

structuring  TCA  clearance  request 

Initial  controller  response 
Altitude  instruction 
Data  update 

Heading/route  instruction 
Speed  instruction 
Approach/ runway  advisory 
PVD  display  update 
Traffic  advisory 
ATIS  advisory 
Altiaeter  setting  advisory 
Transponder  code  assigmaent 
Controller  coordination 

Altitude  instruction 
Data  update 

Controller  coordination 

Heading/route  instruction 
Controller  coordination 

Speed  instruction 

Approach  clearance 

Runway  assignment 

Traffic  advisory 

Pilot  altitude  report 

Pilot  heading/position  report 

Pilot  speed  report 

Miscellaneous  A/C  conaaunlcation 

Frequency  change 

Transponder  code  change 
Approach/runway  advisory 


Pilot 

request 

Altitude  revision 

Controller  coordination 

Route/heading  revision 
Controller  coordination 

Miscellaneous  pilot  request 

General 
latersector 
coord inatlon 

i 

1 

I 

Polntout  acceptance 

IPolntout  initiation 

1 Control  instruction  approval 

^Planning  advisory 

1 

Aircraft  status  advisory 

Oncral 

Data  block  fore tnj/resoval 

'iystem 

.)ptTnt  Ion 

PVD  display  ad  }unt.T?eat 
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Table  4 


Table  5 


R CONTROLLER 

ROUTINE  EVENT  MINIMUM  PERFORMANCE  TIME  ESTIMATES 
OAKLAND  BAY  TRACON*  SYSTEM  1,  2-MAN  TEAM 


v?ontrol  jHandoff  acceptance 

'jurisdiction  Manual  acceptance-si lent 
'transfer  Tower  departure  call 

j Controller  coordination 

I Handoff  initiation-silent 

Controller  coordination 


rcaffic  Initial  pilot  call-in 

structuring  TCA  clearance  request 

Initial  controller  response 
Altitude  instruction 
Data  update 

Heading/route  Instruction 
Speed  Instruction 
Approach/ runway  advisory 
PVD  display  update 
Traffic  advisory 
ATIS  advisory 
AlClneter  setting  advisory 
Transponder  code  asslgnaent 
Contv’oller  coordination 

Altitude  Instruction 
Data  update 

Controller  coordination 

Heading/route  instruction 
Controller  coordination 

Speed  Instruction 

Approach  clearance 

Runway  assignment 

Traffic  advisory 

Pilot  altitude  report 

Pilot  heading/position  report 

Pilot  speed  report 

Miscellaneous  A/G  communication 

Frequency  change 

Transponder  code  change 
Approach/runway  advisory 


Altitude  revision 

Controller  coordination 

Route/heading  revision 
Controller  coordination 

Miscellaneous  pilot  request 


General  I 

Intersector 

coordination: 

1 

i 

Polntout  acceptance 

Pointout  Initiation 

Contr'^l  Instruction  approval 

Planning  advisory 

Aircraft  status  advisory 

G^'nrral 

system 

|f>p»-rntlon 

1 

Data  block  forclng/ronioval 

PVD  display  adjustment 

Table  6 
R CONTROLLER 

ROUTINE  EVENT  MINIMUM  PERFORMANCE  TIME  ESTIMATES 
OAKLAND  BAY  TRACON,  SYSTEM!  1,  2.5-MAN  TEAM 


RouCir.t’ 

Cotit  col  Event  Description 

Performance  Time  by  Task  (man- sec/event ) 

)ata 

Flight 

Inter- 

Face-to- 

Event 

Function 

Basic  t'vent  and 
Suppler.ental  Event 

ilntry/ 

)isplay 

)peratio 

Strip 
Frocess- 
\ ing 

phone 

Communi- 

cation 

Face 

Coiimuni- 

cation 

Total 

• 

Control 

Handoff  acceptance 

0 

jurisdiction 

Manual  acceptance-silent 

0 

transfer 

Tower  departure  call 

0 

Controller  coordination 

3 

3 

Handoff  initiation-silent 

0 

Controller  coordination 

3 

3 

Traffic 

Initial  pilot  call-in 

mm 

1 

structuring 

TCA  clearance  request 

6 

Initial  controller  response 

2 

Altitude  instruction 

3 

Data  update 

2 

Heading/route  instruction 

3 

Speed  instruction 

3 

Approach/runway  advisory 

3 

PVD  display  update 

0 

Traffic  advisory 

3 

3 

AXIS  advisory 

3 

3 

Alcitaecer  setting  advisory 

3 

3 

Transponder  code  assignment 

3 

5 

Controller  coordination 

3 

3 

Altitude  instruction 

5 

5 

Data  update 

2 

2 

Controller  coordination 

3 

3 

Heading/route  instruction 

5 

5 

Controller  coordination 

3 

Speed  instruction 

5 

5 

Approach  clearance 

6 

6 

Runway  assignment 

5 

5 

Traffic  advisory 

5 

5 

Pilot  altitude  report 

mm 

5 

Pilot  heading/position  report 

5 

Pilot  speed  report 

B 

Miscellaneous  A/G  communication 

B 

Frequency  change 

mm 

1 

Transponder  code  change 

2 

Approach/runway  advisory 

3 

H 

Altitude  revision 

6 

2 

8 

Controller  coordination 

3 

3 

Route/heading  revision 

8 

2 

10 

Controller  coordination 

3 

3 

Miscellaneous  pilot  request 

6 

6 

General 

Polntout  acceptance 

3 

3 

intersector 

coordination 

Pointout  initiation 

3 

3 

3 

Control  instruction  approval 

3 

Planning  advisory 

3 

3 

Aircraft  status  advisory 

0 

General 

Data  block  forcing/removal 

0 

system 
joperat  Ion 

PIT?  display  .adjustment 

■ 

H 

0 

58 


to  the  interphone  communication  tasks,  the  data  processing  tasks  required 
for  handoffs,  and  those  data  entry/display  tasks  that  are  not  required 
for  minute-by-minute  PVD  display  update  and  maintenance.  However,  some 
face-to-face  communication  tasks  between  R and  H controllers  are  now 
necessary . 


2.5-man  Team- -We  assume  the  R controller  offloads  some 
flight  strip  processing  and  all  data  entry/display  operation  and  inter- 
phone communication  tasks  to  the  H controller  and  the  coordinator.  The 
resulting  R controller  tasks  in  Table  6 are  obtained  from  Table  5 by 
eliminating  all  task  entries  other  than  A/G  communication,  flight  strip 
processing  and  face-to-face  communication  tasks.  Also,  those  flight 
strip  processing  tasks  (including  handoff  and  transponder  code  assign- 
ment) not  directly  concerned  with  minute-by-minute  traffic  data  mainte- 
nance are  allocated  to  positions  other  than  the  R controller. 


c . R Controller  Event  Performance  Times 

The  controller  minimum  performance  times  required  to  exe- 
cute each  event  are  presented  in  Table  7 for  each  of  the  four  sector  team 
manning  regimes.  Each  event  time  entry  is  the  sum  of  the  component  task 
times  as  shown  in  the  right-hand  columns  of  Tables  3,  4,  5,  and  6;  these 
summaries  are  collated  in  Table  7 to  facilitate  comparisons  between  event 
times  under  each  regime. 


3 . Routine  Workload  Weighting 

The  R controller  routine  workload  weighting  (kj^)  is  calculated 
by  multiplying  event  frequencies  (Table  1)  by  corresponding  event  perfor- 
mance times  (Table  7)  and  summing  the  products  obtained  for  each  sector 
manning  regime  for  each  of  the  six  sectors.  The  resulting  workload  weight- 
ings are  listed  in  Table  8. 


B . Surveillance  Work 


As  discussed  earlier,  surveillance  workload  modeling  is  based  on  the 
assumption  that  1.25  man-sec/aircraf t-min  of  PVD  scanning  work  is  needed 
to  maintain  cognizance  of  traffic  movements.  Surveillance  workload  weight- 
ing is  obtained  by  multiplying  this  scanning  work  constant  by  the  average 
aircraft  transit  time  for  each  sector;  this  is  summarized  in  Table  9.  The 
transit  times  in  Table  9 are  those  reported^^  for  each  sector  by  Oakland 
Bay  TRACON  and  co'^respond  to  the  average  time  aircraft  were  on  each  sector's 
A/G  radio  frequency  during  out  data  collection  sessions. 
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Indicated  event  occurs  at  one-half  the  freouency  rate  shown  in  Table  1. 
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Table  8 


R CONTROLLER  ROUTINE  WORKLOAD  WEIGHTINGS 
OAKLAND  BAY  TRACON,  SYSTEM  1— ARTS  III  BASE 


Sector 

R Controller  Routine  Workload  Weight- 
ing, k. , by  team  (man- sec/aircraft) 

1-Man 

Team 

1. 5-Man 
Team 

2 -Man 
Team 

2 . 5 -Man 

Team 

AR-1,  Woods ide  Final 

56 

50 

49 

46 

AR-2,  Foster  Final 

46 

42 

41 

39 

AR-9,  South  Feeder 

48 

41 

38 

34 

AR-10,  North  Feeder 

47 

41 

38 

32 

DR-1,  Sutro  Departure 

55 

43 

39 

39 

DR-2,  Richmond  Departure 

66 

56 

51 

48 

C . Conflict  Processing  Work 

Our  formulation  of  the  conflict  processing  workload  requires  esti- 
mating the  frequency  of  potential  conflict  events  and  their  processing 
task  times. 


1 . Conflict  Event  Frequency 

The  traffic  operation  and  route  pattern  characteristics  for 
each  of  the  six  sectors  were  described  in  a preceding  section  of  this 
report.  We  use  the  mathematical  relations  described  in  Appendix  A to 
model  each  sector's  traffic  patterns  and  calculate  the  expected  number 
of  potential  conflicts.  These  calculations  give  the  frequency  factors 
(ec>  Cq,  and  e^,  respectively),  that  measure  the  frequency  of  poten- 

tial crossing,  local  merging,  overtaking,  and  coordinated  approach  merg- 
ing conflicts.  These  calculated  frequency  factors  are  summarized 
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for  each  sector  in  Table  10.  Since  approach  control  procedures  vary  ac- 
cording to  visibility  conditions,  we  model  both  visual  approach  and  in- 
strument approach  operations. 


a . Visual  Approach  Operations 

Under  visual  approach  conditions,  simultaneous  side-by- 
side  approaches  to  the  SFO  parallel  runways  are  normal.  For  modeling 
purposes,  we  assume  the  two  feeder-and-f inal  pairs.  South  Feeder/Woods ide 
Final  (AR-9/AR-1)  and  North  Feeder/Foster  Final  (AR-lO/AR-2)  are  opera- 
tionally independent;  AR-9/AR-1  traffic  uses  Runway  28L  and  AR-lO/AR-2 
traffic  uses  Runway  28R.  Therefore,  traffic  along  one  of  these  approach 
courses  need  not  be  sequenced  and  spaced  with  traffic  along  the  other 
approach  course,  and  no  coordinated  approach  merging  conflict  situations 
exist.  Thus,  under  visual  approach  operations,  the  corresponding  fre- 
quency factor  in  Table  10  is  zero  for  each  sector. 

The  remaining  frequency  factors  shown  in  Table  10  reflect 
the  conflict  situations  internal  to  each  sector  (i.e.,  those  potential 
conflicts  are  resolved  by  each  sector  team  without  formal  intersector 
coordination) . For  example,  we  find  that  overtaking  situations  are  most 
frequent  in  the  final  sectors.  The  feeder  sectors  must  resolve  crossing 
and  overtaking  conflicts  and  conduct  local  mergings  of  traffic  under 
their  jurisdiction.  The  departure  sectors  primarily  resolve  crossing 
situations,  but  are  also  concerned  with  overtaking  and  local  merging 
conflicts . 


b . Instrument  Approach  Operations 

In  this  case,  all  traffic  approaching  the  SFO  parallel  run- 
way complex  must  be  mutually  sequenced  and  spaced,  and  the  resolution  of 
potential  approach  merging  conflicts  must  be  coordinated  by  the  two  feeder 
sector  teams.  Our  mathematical  modeling  for  this  potential  conflict  situ- 
ation obtains  a frequency  factor  of  3.8  (conflicts/hr) /(aircraft/hr) 
However,  since  both  feeder  sectors  are  involved  in  the  resolution  of  each 
coordinated  approach  merge,  this  frequency  factor  applies  to  both  sectors, 
as  shown  in  Table  10.  (The  resulting  double  counting  of  approach  merge 
frequencies  will  be  counteracted  by  the  methodology  we  use  to  estimate 
conflict  event  times,  which  we  will  explain  subsequently.) 

Except  for  arrival  sector  overtaking  situations,  we  assume 
that  the  frequency  of  each  sector's  remaining  potential  conflicts  is  the 
same  under  instrument  approaches  as  for  visual  approaches,  since  their 
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Tabic  10 

CONFLICT  F,VENT  FREQUENCY  ESTIMATES 
OAKLAND  BAY  TRACON , SYSTEM  1 - ARTS  III  BASE 


Cont  i let  Event 

Frequency  Factor 

1 (Conflicts/Hr) 

/ (Atrcraf t /Hr)‘ 1 

Visual  Approach  Operations 

Local 

Coord inated 

Sector 

Crossing , e^ 

Merging , e 

m 

Overtaking,  e 

Approach  Merging,  e 

a 

AR-1,  Woodside  Final 

0 

0 

6.5  X lO"^ 

0 

AR-2,  Foster  Final 

0 

3.2  X 10"^ 

10.6  X 10"^ 

0 

AR-9,  South  Feeder 

0 

4.6  X lO"^ 

1.4  X lO'^ 

0 

AR-10,  North  Feeder 

-3 

1.5  X 10 

^■.3  X lO"^ 

3.7  X lO'^ 

0 

DR-1,  Sutro  Departure 

5,7  X lO"^ 

0.7  X lO"^ 

2.3  X lO'^ 

0 

DR-2,  R -hmond  Departure 

4.5  X 10'^ 

0 

L 'S  X lO"^ 

0 

Instrument  Approach  Operations 

Local 

Coordinated 

Sector 

Crossing , e^ 

Merging, e 

m 

Overtaking ,e^ 

Approach  Merging,  e^ 



AR-1,  Woodside  Final 

0 

0 

13.0  X 10"^ 

0 

AR-2,  Foster  Final 

3.2  X lO"^ 

21.2  X lO"^ 

0 

AR-9,  South  Feeder 

0 

4.6  X lO"^ 

-3 

2.8  X 10 

3.8  X lO"^ 

AR-10,  North  Feeder 

1.5  X 10*^ 

3.3  X 10”^ 

_3 

7.4  X 10 

3.8  X lO"^ 

DR-1,  Sutro  Departure 

5.7  X 10”^ 

0.7  X lO"^ 

-3 

2.3  X 10 

0 

DR-2,  Richmond  Departure 

1 

4.5  X 10”^ 

0 

-3 

0.8  X 10 

0 

corresponding  procedural  requirements  do  not  change-  However,  each  final- 
and-feeder  pair  must  increase  in-trail  aircraft  spacings  in  order  to  inte- 
grate its  traffic  with  those  of  the  other  sector  pair  along  the  parallel 
final  approach  courses.  To  approximate  this  situation,  we  assume  that  the 
in-trail  aircraft  spacings  required  will  be  double  those  of  the  visual 
approach  case,  such  as  would  occur  if  each  feeder  alternated  aircraft 
‘ deliveries  to  the  final  approach  course  with  the  other.  This  assumption 

will  double  the  calculated  frequency  factor  estimates,  which  are  adjusted 
accordingly  in  Table  10  for  the  feeder  and  final  sectors  under  instrument 
approach  operations. 

2 . Conflict  Event  Performance  Time 

The  minimum  time  required  for  potential  conflict  event  process- 
ing is  the  sum  of  the  minimum  times  required  to  perform  detection  and 
assessment,  coordination,  and  resolution  tasks.  Our  estimates  of  the 
minimum  task  performance  and  event  times  required  by  the  composite  sector 
team  are  summarized  in  Table  11  for  crossing,  local  merging,  overtaking, 
arid  coordinated  approach  merging  situations. 


Table  11 
COMPOSITE  TEAM 

CONFLICT  EVENT  PERFORMANCE  TIME  ESTIMATES 
OAKLAND  BAY  TRACON,  SYSTEM  1--ARTS  III  BASE 


a . Composite  Team  Conflict  Tasks 

The  detection  and  assessment  task  time  estimate  (which  is 
20  man-sec  for  each  conflict  event)  corresponds  to  the  results  obtained 
from  our  previous  enroute  ATC  data  analyses^  in  which  we  reviewed  with 
controllers  video-tape  playbacks  of  their  conflict  processing  activities 
Spot  checks  of  Bay  TRACON  controller  activities  found  that  no  change  was 
warranted  in  this  previous  estimate  of  detection  and  assessment  task 
t ime . 


The  estimates  of  coordination  and  resolution  task  time  were 
obtained  directly  from  data  measurements  made  at  Bay  TRACON.  Table  11 
shows  that  intersector  coordination  (5  man-sec)  is  needed  between  feeder 
sector  teams  to  negotiate  (by  means  of  face-to-face  oral  conversation  or 
hand  signals)  and  agree  on  the  order  in  which  each  sector's  aircraft  are 
sequenced  onto  the  final  approaches  during  instrument  approach  operations. 
Such  communications  apply  only  to  the  coordinated  approach  mergings.  The 
resolution  task  times  vary  according  to  the  type  of  potential  conflict 
event.  The  crossing  conflict  resolution  time  (20  man-sec)  is  longer  than 
that  of  the  others  because  controllers  rely  on  vectoring,  altitude,  and 
speed  controls  to  correct  conflicts  and  often  later  instruct  an  aircraft 
to  return  to  its  original  course.  Merging  conflict  resolution  time  (15 
man-sec)  normally  consists  of  speed  controls  with  some  vectoring,  while 
overtaking  conflict  resolution  time  (10  man-sec)  generally  consists  of 
only  speed  controls. 


b . R Controller  Conflict  Tasks 

The  tasks  represented  in  Table  11  for  crossing,  local  merg- 
ing, and  overtaking  situations  are  performed  by  each  sector's  R control- 
ler, no  matter  what  team  manning  regime  is  in  effect,  and  the  corresponding 
task  times  represent  his  workload  requirement  for  each  such  conflict  event. 
However,  the  R controller  workload  associated  with  a coordinated  approach 
merging  situation  will  vary  under  different  manning  regimes.  Consider  the 
situations  presented  in  Table  12  where  R controller  task  requirements  are 
shown  dependent  on  whether  or  not  a coordinator  is  involved  and  to  which 
of  the  two  feeder  R controllers  overtly  resolves  the  approach  merging. 

With  reference  to  the  non-coordinator  operation  (i.e.,  1-man  or  2-man 
teams),  we  assume  each  approach  merging  conflict  will  require  both  feeder 
R controllers  to  detect,  assess,  and  coordinate  the  situation;  therefore, 
both  R controllers  spend  time  on  these  tasks  even  though  only  one  approach 
merging  conflict  is  involved.  In  our  field  observations,  however,  we  found 
that  generally  only  one  of  the  two  R controllers  is  needed  to  resolve  the 
merge  via  A/G  communications.  He  issues  the  appropriate  instructions  to 
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Table  12 


COORDINATED  APPROACH  MERGING 
R CONTROLLER  CONFLICT  EVENT  PERFORMANCE  TIME  ESTIMATES 

OAKLAND  BAY  TRACON,  SYSTEM  1~ARTS  III  BASE 


R-Controller  Minimum  Performance  Time  by  Task 

Sector 

(man- 

sec/coordinated  merging  event) 

Operation 

Detection 
and  Assessment 

■ 

Coordination 

Average 

Without  ^ 

Coordinator 

AR-9  (or  -10) 

20 

5 

15 

40 

32.5 

AR-10(or  -9) 

20 

5 

0 

25 

With  ^ 

Coordinator' 

AR-9  (or  -10) 

10 

3 

15 

28 

20.5 

AR-10(or  -9) 

10 

3 

0 

13 

1-man  and  2-man  sector  team  manning  regimes 
^1. 5-man  and  2.5-man  sector  team  manning  regimes 


fit  his  aircraft  into  spacings  built  into  the  other  controller's  traffic 
stream.  (Additional  control  work  required  to  maintain  aircraft  in  proper 
relative  positions  is  assumed  to  be  represented  by  our  models  of  overtaking 
conflict  work.)  Therefore,  the  total  work  time  required  by  both  R control- 
lers to  process  a single  coordinated  approach  merging  conflict  is  65  man- 
sec,  which  results  in  an  average  event  performance  time  of  32.5  man-sec  for 
each  R controller. 
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Regarding  the  coordinator-supported  operations  (i.e.,  1.5- 
man  or  2.5-man  team  regimes)  in  Table  11,  we  assume  the  coordinator  will 
make  the  sequencing  decisions,  and  this  would  reduce  each  R controller's 
detection  and  assessment  task  time  requirements  to  10  man-sec.  The  coor- 
dinator will  issue  sequencing  directives  simultaneously  to  each  R con- 
troller, taking  3 man-sec  of  each  of  their  time  for  coordination.  The 
resulting  average  event  performance  time  is  20.5  man-sec  for  each  R con- 
troller. 


For  our  modeling  purposes,  the  R controller's  performance 
times  (tj,,  tjjj,  t^,  and  t^,  respectively)  for  the  potential  conflict  events 
in  crossing,  local  merging,  overtaking,  and  coordinated  approach  merging 
situations  measured  in  man-sec/conflict  are: 

tj,  = 40,  for  1-man,  1.5-man,  2-man,  and  2.5-man  teams; 

tjj,  = 35,  for  1-man,  1.5-man,  2-man,  and  2.5-man  teams; 

tg  = 30,  for  1-man,  1.5-man,  2-man,  and  2.5-man  teams; 

tg  = 32.5,  for  1-man  and  2-man  teams; 

= 20.5,  for  1.5-man  and  2.5-man  teams. 


3 . Conflict  Workload  Weighting 

R controller  conflict  workload  weightings  (k2,  ^3,  ^4,  and  k^) 
are  estimated  by  multiplying  the  conflict  event  frequencies  (Table  10)  by 
the  corresponding  performance  time  (see  above).  Results  of  these  calcula- 
tions for  visual  and  instrument  approach  conditions  in  each  of  the  six 
sectors  are  presented  in  Table  13. 


D . Workload  Weighting  Application 

The  routine,  surveillance,  and  conflict  workload  weighting  data  are 
used  to  estimate  sector  capacities  for  each  sector  team  manning  regime. 

We  defer  to  a subsequent  section  of  this  report  the  presentation  of  the 
resulting  sector  capacity  estimates  for  ARTS  III  operations  so  that  we 
may  then  make  comparisons  between  these  capacity  estimates  and  those  cor- 
responding to  the  UG3RD  system  alternatives. 
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R CONTROLLER  CONFLICT  WORKLOAD  WEIGHTING 


Indicated  crossing,  local  merging  and  overtaking  conflict  workload  weightings  are  for  any  of  the  1-man,  1.5-man, 
2-man,  and  2.5-raan  sector  team  manning  regimes. 


VII  BAY  TRACON  UG3RD  SYSTEMS  MODELS 


In  this  section  we  describe  the  technological  and  operational  aspects 
of  various  proposed  UG3RD  automation  features  and  assess  their  impact  on 
R controller  workload  for  the  six  Bay  TRACON  sectors.  These  systems  are: 

• Automated  data  handling  (ADH) 

• Basic  metering  and  spacing  (M&S) 

• Conflict  probe 

• Area  navigation  (RNAV) 

• Discrete  address  beacon  system  (DABS)  data  link 

• DABS-based  intermittent  positive  control  (IPC)  • 

Our  UG3RD  feature  descriptions  are  based  on  FAA  engineering  and  oper- 
j ational  preliminary  design  plans  for  terminal  ATC  and  UG3RD  ATC  System, 

j on  consultations  with  FAA  Oakland  Bay  TRACON,  Los  Angeles  TRACON  and  Head- 

quarters personnel,  and  on  our  experience  and  judgment.  We  consider  each 
I _ feature,  in  the  order  of  the  above  list,  to  be  added  incrementally  to  the 

preceding  feature.  This  procedure  obtains  a set  of  alternative  ATC  sys- 
tems, each  of  which  includes  the  features  of  its  predecessor  system,  as 
well  as  its  own  additional  feature. 


The  current  ARTS  III  System  modeled  in  the  preceding  section  of  this 
report  is  taken  as  the  base  system.  Beginning  with  the  ARTS  III  model, 
we  will  incrementally  adjust  the  event  frequency  and  performance  time  pa- 
rameters to  describe  the  operational  characteristics  of  each  successive 
UG3RD  system.  This  process  will  provide  revised  workload  weightings  for 
each  successive  UG3RD  system  and  enable  determination  of  sector  capacities 
under  each  system.  The  workload  descriptions  stem  from  our  views  on  how 
the  various  features  might  be  implemented. 


A.  Automated  Data  Handling  (System  2) 


Automated  data  handling  provides  for  the  automatic  distribution  of 
flight  data  among  sectors  and  facilities.  The  main  automation  aspect  of 
this  feature  is  the  addition  at  sector  positions  of  an  electronic  tabular 
flight  data  display  system. 


I 
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The  tabular  display  can  be  highly  important  because  of  its  impact  on 
sector  controller  activities  and  its  implications  for  sector  configuration 
redesign.  The  tabular  display,  an  electronic  alphanumeric  presentation 
of  flight  data,  would  replace  the  flight  progress  strips  and  paper  scratch 
pads  on  which  flight  data  are  currently  found.  The  display  is  assumed  to 
be  automatically  refreshed  by  the  FDP  computer  system  and  to  be  accessible 
by  sector  team  keyboard  entry  devices.  It  is  designed  to  eliminate  manual 
flight  strip  processing  by  consolidating  all  on-line  data  presentation  and 
maintenance  into  computer  interactive  format  (thus  eliminating  the  current 
system  requirement  for  redundant  simultaneous  keyboard  and  flight  strip 
processing  operations)  and  to  facilitate  sector  team  handoff  and  pointout 
operations . 

The  automatic  transfer  of  flight  data  and  the  elimination  of  current 
paper  flight  strip  processing  would  mean  that  a flight  data  position  would 
no  longer  be  necessary,  provided  that  the  automated  system  operates  with 
a high  degree  of  failure  recovery.  We  expect  that,  with  the  advent  of  ad- 
vanced microprocessing  technology,  continuity  of  tabular  display  operations 
could  be  provided  through  redundant  ADH  software/hardware  equipment. 
Otherwise,  if  such  fault  tolerance  were  not  provided,  an  important  produc- 
tivity benefit  of  automated  data  handling  could  not  be  realized,  because 
flight  strip  printers  and  flight  data  processors  would  probably  be  needed 
for  back-up  purposes.  (Of  course,  the  flight  data  position  is  also  used 
for  on-the-job  training  of  controllers,  and  eliminating  this  position 
would  require  adjustments  in  controller  training  programs.) 

Quite  apart  from  the  issue  of  sector  team  manpower  support,  the  tab- 
ular display  should  reduce  R controller  workload  requirements  and  thereby 
increase  sector  traffic  capacities.  We  discuss  R controller  workload 
changes  in  the  following  paragraphs. 

1 . ADH  Workload  Model 

The  ADH  tabular  display  will  primarily  affect  routine  work  by 
altering  many  of  the  sector  team's  data  maintenance  activities.  We  foresee 
no  effect  on  our  surveillance  or  conflict  work  models. 

a . Composite  Team  Routine  Tasks 

Our  interpretations  of  the  effects  of  tabular  display  on 
the  composite  team's  routine  task  performance  time  are  summarized  in  Ta- 
ble lA.  The  parenthesis  around  entries  in  the  table  indicates  task  times 
under  the  ARTS  III  Base  System  (Table  2) . Entries  adjacent  to  the  paren- 
thesis are  the  revised  task  times  corresponding  to  automated  data  handling. 
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Table  U 
COMPOSITE  TEAM 

ROUTINE  EVENT  MINIMUM  PERFORMVNCr  T’ME  ESTIMATES 
OAKLAND  BAY  TRACON,  SYSTEM  2— AUTOVuMuD  DATA  HANDLING 


Foufir.r  Control  Event  Description 

Perfornance  Time 

by  Task 

(man-sec/evenc)*  ' 

Event 
Func  r ion 

Basic  Evc^nC  and 
Supplemental  Event 

A/C  Com- 
munica- 
tion 

Data 

Entry/ 

Display 

i}perat{on 

Flight 

Strip 

Interphone 

Communica- 

tion 

Face-to- 
Face  Com- 
munication ; 

Control 

jurisdiction 

transfer 

Handoff  acceptance 

Manual  acccptance-silent 

Tower  departure  call 
Controller  coordination 

2 

1 

0(2) 

0(2) 

6 

1 

! 

3 < 

Handoff  initiation^silent 
Controller  coordination 

1(3) 

6 

j 

3 

Traffic 

structuring 

Initial  pilot  call-in 

TCA  clearance  request 

U 

4 

UO) 

10 

0(1) 

0(6) 

4(0) 

Initial  controller  response 
Altitude  instruction 

Data  update 

Beading/rpute  instruc..  on 
Speed  Instruction 

Approach/ runway  advisory 

PVD  display  tjodate 

Traffic  advisory 

ATIS  advisory 

Altimeter  setting  advisory 
Transponder  code  assignment 
Controller  coordination 

■ 

■ 

3(0) 

3 

3 

0(2) 

0C2) 

5 

3 

Altitude  instruction 

Data  update 

Controller  coordination 

5 

3(0) 

0(2) 

5 

3 

Heading/route  instruction 
Controller  coordination 

5 

5 

3 

Speed  instruction 

5 

Approach  clearance 

6 

Runway  assignment 

5 

Traffic  advisory 

5 

Pilot  altitude  report 

5 

Pilot  heading/position  report 

5 

Pilot  speed  report 

5 

Miscellaneous  A/C  communication 

5 

Frequency  change 

Transponder  code  change 
Approach/runuay  advisory 

4 

2 

3 

1(0) 

0(1) 

Pilot 

request 

Altitude  revision 

Controller  coordination 

b 

3(0) 

0(2) 

5 

Route/heading  revision 
Controller  coordination 

8 

3(0) 

0(2) 

5 

i 

3 

Miscellaneous  pilot  request 

6 

General 

Intersector 

coordination 

Polntout  acceptance 

Pointout  Initiation 

Control  instruction  approval 

3 

3(0) 

0(6) 

0(6) 

5 

0(3) 

0(3) 

3 

Planning  advisory 

5 

3 

Aircraft  status  advisory 

5 

1 

Cener.-il 
system 
oper  It  Ion 

Data  block  forcing/removal 

I’VD  display  adjustment 

3 

3 

! 

1 

^System  1 performance  times  are  indicated  in  parentheses. 
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All  other  entries  in  Table  14  are  identical  to  those  in  Table  2,  since  we 
assume  that  these  tasks  will  not  be  affected  by  tabular  display  operations 
and  must  be  performed. 


With  reference  to  the  tasks  under  the  control  jurisdiction 
transfer  function  shown  in  Table  14,  we  assume  the  FDP  computer  system 
will  be  capable  of  recognizing  handoff  initiation  and  acceptance  events 
and  automatically  indicating  their  occurrence  on  a tabular  display  of 
flight  data  for  each  aircraft.  This  capability  eliminates  the  2 man-sec 
flight  strip  processing  currently  needed  to  manually  arrange  or  distribute 
the  strips  (or  to  mark  paper  scratch  pads)  . However,  the  keyboard  data 
entry/display  operations  are  still  needed  for  silently  initiating  or  ac- 
cepting handoffs  (and  thereby  triggering  an  update  of  the  computerized 
tabular  display) . Tower  departure  calls  would  not  be  needed  if  the  tower 
controllers  used  simplified  button-pushing  operations  to  report  aircraft 
takeoff;  the  ADH  system  would  use  these  reports  for  automatically  updating 
TRACON  tabular  flight  data  displays  and  to  check  for  correct  track  acqui- 
sition. Silent  handoff  initiation  could  be  manually  performed  on  the  air- 
craft's electronic  flight  data  tabulation  by  a 1 man-sec  button-pushing 
operation  rather  than  by  the  current  3 man-sec  data  entry/display  opera- 
tion. 

For  traffic  structuring  and  pilot  request  events,  the 
flight  strip  processing  tasks  become  keyboard  data  entry/display  opera- 
tions. Event  recording  tasks  (e.g.,  recording  the  occurrence  of  a pilot 
call-in  or  frequency  change  instruction)  are  assumed  to  be  accomplished 
by  simple  direct  entry  devices  on  the  tabular  display;  they  would  not  take 
longer  than  the  current  flight  strip  performance  times  of  1 man-sec  each. 
However,  preparation  of  new  flight  files  for  unexpected  aircraft  "pop-ups" 
would  still  need  to  be  performed,  requiring  a 10  man-sec  data  entry /display 
operation;  however,  the  6 man-sec  flight  strip  preparation  is  eliminated. 
Under  2-man  or  2.5-man  sector  team  operations,  we  assume  the  H controller 
performs  the  necessary  keyboard  operations  for  the  "pop-ups",  and  we  allow 
an  additional  4 man-sec  face-to-face  communication  so  that  the  H controller 
may  obtain  the  necessary  flight  data  from  the  R controller  (who  has  ob- 
tained the  data  from  the  pilot  via  A/G  communication) . 

Certain  data  update  operations  currently  recorded  on  flight 
strips  (e.g.,  altitude  and  route/heading  instructions  or  requests)  would 
need  to  be  replaced  by  new  keyboard  data  entry/display  operations.  Since 
current  keyboard  operations  for  computer  data  entries  require  3 man-sec 
to  perform,  it  is  assumed  that  data  entry  operations  using  the  tabular 
display  would  also  take  this  long.  Therefore,  implementing  the  tabular 
display  would  actually  increase  data  entry  operations  by  1 man-sec  over 
the  current  flight  strip  entries.  The  3 man-sec  data  entry  time  may  be 
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an  over-estimate  if  one  considers  the  possibility  of  designing  improved 
man-machine  interaction  devices  as  part  of  the  tabular  display,  but  it  is 
nevertheless  adopted  for  lack  of  more  precise  data. 

The  keyboard  data  entry/display  operations  required  for 
accepting  handoffs  could  also  give  a visual  signal  (e.g.,  blinking  light) 
which  could  be  removed  by  pushing  a button  after  issuing  the  radio  fre- 
quency change.  We  assume  that  a 1 man-sec  manual  button  push  would  re- 
place the  current  1 man-sec  flight  strip  marking  associated  with  a fre- 
quency change  instruction. 

Pointouts  currently  initiated  by  interphone  communications 
cause  the  recipient  sector  team  to  force  a data  block  onto  its  own  PVD 
display  as  part  of  the  pointout  acceptance  event.  The  receiving  sector 
has  no  flight  strip  on  the  aircraft  in  question,  and  verbal  intersector 
communications  are  used  to  transmit  needed  flight  data  as  well  as  to  con- 
firm pointout  recognition.  The  interphone  and  associated  face-to-face 
communications  could  be  eliminated  by  the  tabular  display  if  both  the 
pointout  initiation  and  acceptance  events  are  performed  by  silent  keyboard 
data  entry/display  operations.  The  pointout  initiation  would  automati- 
cally force  the  PVD  data  block  display  and  simultaneously  force  pertinent 
flight  data  onto  the  receiving  sector's  tabular  display,  thus  eliminating 
the  need  for  voice  consultations.  A manual  silent  pointout  acceptance 
would  confirm  pointout  recognition.  As  shown  in  Table  14,  we  assume  the 
ADH  pointout  initiation  and  acceptance  events  require  3 man-sec  data  entry/ 
display  operations  but  no  interphone  or  face-to-face  communications. 

No  effect  on  A/G  communication  task  requirements  is  pro- 
jected since  the  tabular  display  automates  controller  data  maintenance 
activities  rather  than  the  controller/pilot  interface. 

b.  R Controller  Routine  Tasks 

We  allocate  the  composite  team  routine  task  time  require- 
ments to  the  R controller  for  each  of  the  four  sector  team  manning  regimes 
as  shown  in  Tables  15,  16,  17,  and  18.  The  allocations  parallel  those 
made  for  the  ARTS  III  Base  System;  The  coordinator  performs  routine  in- 
terphone tasks  and,  for  the  1.5-man  team,  half  the  handoff  events;  the  H 
controller  performs  keyboard  data  entry/display  tasks  where  appropriate 
and  interphone  communications  if  the  coordinator  position  is  not  manned; 
face-to-face  communications  apply  only  to  the  multi-man  team  regimes. 
Regarding  pointout  acceptance  and  initiation  events  for  the  2-man  and 
2.5-man  teams,  we  assume  the  necessary  manual  tasks  are  performed  by  the 
H controller,  but  the  R controller  must  observe  the  pointout-related 
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Table  13 


R CONTROLLER 

ROUTINE  irVENT  MINIMA  PERFORhtANCE  TIME  ESTIMATES 
OAKLAND  BAY  TRACON,  SYSTEM  2,  1-MAN  TEAM 


Control  Event  DviicripCion  Perfortiar.ce  Tine  by  Task  (nan-st-c/event ) 


A/G 

Data  , 

t Flight 

Inter- 

Kaco-l  o- 

Event 

Basic  Event  and 

('orinuni- 

Strip 
; Process- 

phone 

' Face 

Total 

Funcciou 

SiippiciT.s-atal  Event 

cat  ion 

ing 

cation 

1 cation 

;:,'ntrol 

Hindoff  acceptance 

0 

jurisdiction 

Manual  acceptance-silent 

2 

2 

transfer 

Tower  departure  call 

0 

Controller  coordination 

6 

6 

Handof f initiation-silent 

1 

1 

Controller  coordination 

6 

6 

Traffic 

Initial  pilot  call-in 

4 

1 

5 

Structuring 

TCA  clearance  request 

4 

10 

14 

Initial  controller  response 

2 

2 

Altitude  instruction 

3 

3 

Data  update 

3 

3 

Heading/ route  instruction 

3 

3 

Speed  Instruction 

3 

3 

Approach/runway  advisory 

3 

3 

PVD  display  update 

3 

3 

Traffic  advisory 

3 

3 

ATIS  advisory 

3 

3 

Altimeter  setting  advisory 

3 

3 

Transponder  code  assignoenC 

3 

3 

6 

Controller  coordination 

5 

5 

Altitude  instruction 

5 

5 

Data  update 

3 

3 

Controller  coordination 

5 

5 

Heading/route  instruction 

5 

5 

Controller  coordination 

5 

5 

Speed  Instruction 

5 

5 

Approach  clearance 

6 

6 

Runway  assignment 

5 

5 

Traffic  advisory 

5 

5 

Pilot  altitude  report 

5 

5 

Pilot  heading/position  report 

5 

5 

Pilot  speed  report 

5 

5 

Miscellaneous  A/G  cottmunication 

5 

5 

Frequency  change 

4 

1 

5 

Transponder  code  change 

2 

Approach/runway  advisory 

3 

3 

Pilot 

Altitude  revision 

request 

Controller  coordination 

5 

Routc/heading  revision 

8 

^D^H 

Controller  coordination 

Miscellaneous  pilot  request 

B 

■ 

B 

|Ceneral 

Pointout  acceptance 

BB 

[intersector 

Icoordlnatlon 

Pointout  initiation 

1 

H 

BB 

1 

Control  instruction  approval 

Planning  advisory 

Aircraft  status  advisory 

HI 

n 

Bl 

im 

B 

general 

Dat«i  block  forclng/reaoval 

3 

3 

'systera 

Icperntlon 

PVD  display  adjustment 

3 

3 
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Table  16 


R CONTROLLER 

ROUTINE  EVENT'  MINIMUM  PERFORMANCE  TIME  ESTIMATES 
OAKLAND  BAY  TRACON,  SYSTEM  2,  1.5-MAN  TEAM 


Routine  Cuntrol  Event  DcocripCion 


Event 

Function 


Basic  Event  and 
Supplemental  Event 


Control  Handoff  acceptance 

jurisdiction  Manual  acceptance-silcnt 
transfer  \ Tower  departure  call 

I Controller  coordination 

jHandof f initiation-silent 
1 Controller  coordination 


Perfomance  Tia\e  by  Task  (man-sec /event) 


I Data,  Flight 

ProceL- 

^ tion  ing 


Inter-  Face-to- 
phone  Face 
Conintuni-  Coinmunl- 
catlon  cation 


fraf fic 
structuring 

Initial  pilot  call-in 

TCA  clearance  request 

Initial  controller  response 
Altitude  instruction 

Data  update 

Heading/route  instruction 
Speed  instruction 
Approach/runvay  advisory  ' 

PVD  display  update 

Traffic  advisory 

ATIS  advisory 

Altimeter  setting  advisory 
Transponder  code  assignment 
Controller  coordination 

Altitude  instruction 

Data  update 

Controller  coordination 

Heading/route  instruction 
Controller  coordination 

1 

Speed  instruction 

Approach  clearance 

Runway  assignment 

Traffic  advisory 

Pilot  altitude  report 

Pilot  heading/position  report 

Pilot  speed  report 

Miscellaneous  A/G  coinmunication 

Frequency  change 

Transponder  code  change 
Approach/runway  advisory 

Pilot 

Altitude  revision 

request 

Controller  coordination 

Route/heading  revision 

Controller  coordination 

1 Miscellaneous  pilot  request 

General 

intersector 

coordination 


jPolntout  acceptance 
JPointout  initiation 
! Control  instruction  approval 
I Planning  advisory 
lAircrafC  status  advisory 


3 


Table  17 


R CONTROLLER 

ROUTINE  EVENT  PERFORMANCE  TIME  EST!^UTES 

OAKLAND  BAY  TRACON,  SYSTDl  2»  2-MAN  TEAM 


Routine  Control  Evl-iic  Description  : Perfornar.ee  Tine  by  Task  (man-sec/event ) 


Event 

Function 

Basic  Event  and 
Supplemental  Event 

A/G 

Coir.muni- 
ent ion 

Data 

lion 

i flight 
! Strip 

1 Process- 

Inter- 
1 phoi^e 
Communi- 
cation 

, Face-co- 
: Face 
! Coirrmni- 
1 cation 

Total 

''ontrol 

jurisdiction 

transfer 

Handoff  acceptance 

Manual  acceptance-silent 

Tower  departure  call 

Controller  coordination 

Handof f initiation-silent 
Controller  coordination 

3 

3 

0 

0 

0 

3 

0 

3 

Traffic 

Initial  pilot  call-in 

k 

1 

5 

structuring 

TCA  clearance  request 

4 

4 

8 

Initial  controller  response 

2 

2 

Altitude  instruction 

3 

3 

Data  update 

0 

Heading/route  instruction 

3 

3 

Speed  instruction 

3 

3 

Approach/runway  advisory 

3 

3 

PVD  display  update 

3 

3 

Traffic  advisory 

3 

3 

ATIS  advisory 

3 

3 

Altimeter  setting  advisory 

3 

3 

Transponder  code  assignment 

3 

3 

Controller  coordination 

3 

3 

Altitude  Instruction 

5 

5 

Data  update 

0 

Controller  coordination 

3 

3 

Heading/route  instruction 

5 

5 

Controller  coordination 

3 

3 

Speed  instruction 

5 

5 

Approach  clearance 

6 

6 

Runway  assignment 

5 

5 

Traffic  advisory 

5 

5 

Pilot  altitude  report 

5 

5 

Pilot  heading/position  report 

5 

5 

Pilot  speed  report 

5 

5 

Miscellaneous  A/G  coemunication 

5 

5 

Frequency  change 

4 

1 

5 

Transponder  code  change 

2 

2 

Approach/runway  advisory 

1 

3 

3 

Pilot 

Altitude  revision 

6 

3 

9 

request 

Controller  coordination 

3 

3 

Route/heading  revision 

8 

3 

11 

Controller  coordination 

3 

3 

Miscellaneous  pilot  request 

6 

6 

General 

Pointout  acceptance 

3 * 

3 

intersector 

3 * 

3 

coordination 

Contr'^l  instruction  approval 

3 

Planning  advisory 

3 

3 

Aircraft  status  advisory 

0 

Oenecal 

Data  block  forcing/rcmoval 

3 

3 

oyntera 

PVD  dibpl.iy  adjustment 

3 

3 

joparat  f on 

1 

Operational  CoRnlzance 
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Table  18 


R CONTROLLER 

ROUTINE  EVENT  MINIMUM  PERFORMANCE  TIME  ESTIMATES 
OAKLAND  BAY  TRACON,  SYSTEM  2,  2.5-MAN  TEAM 


Routine  Control  Event  Doacriptioa 


Event 

Function 


Basic  Event  and 
Supplenental  Event 


I 


Performance  Tine  by  Task  (man-sec/event) 

A/G  .Data , Flight  Inter-  iFace-to- 

StTiD  pHone  I Facv  _ ^ - 
Process-  Conununi-lcoitcauni-  Total 
at  ion  ^fon  Ing  cation  cation 


[Control  Handoff  acceptance 

(jurisdiction  Manual  acceptance-silent 
transfer  ! Tower  departure  call 

I Controller  coordination 

Handoff  initiation-silent 
1 Controller  coordination 


rraffic  I Initial  pilot  call-in 
structuring  TCA  clearance  request 

Initial  controller  response 
Altitude  instruction 
Data  update 

Heading/route  instruction 
Speed  instruction 
Approach/runuay  advisory 
PVD  display  update 
Traffic  advisory 
ATIS  advisory 
Altimeter  setting  advisory 
Transponder  code  assignment 
Controller  coordination 

Altitude  instruction 
Data  update 

Controller  coordination 

Heading/route  instruction 
Controller  coordination 

Speed  instruction 

Approach  clearance 

Runway  assignment 

Traffic  advisory 

Pilot  altitude  report 

Pilot  heading/position  report 

Pilot  speed  report 

Miscellaneous  A/G  communication 

Frequency  change 

Transponder  code  change 
Approach/runway  advisory 


Pilot 

Altitude  revision 

request 

Controller  coordination 

Route/heading  revision 

1 

Controller  coordination 

1 

1 

1 Miscellaneous  pilot  request 

jCeneral 

isystem 

|:ip.'rntton 


I Data  block  forcing/removal 
PVD  dl!;play  adjustment 


Operational  cognizance 
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display  data  to  maintain  cognizance  of  these  activities.  Therefore,  the 
R controller's  "operation  cognizance"  requirements  are  considered  to  re- 
sult in  3 man-sec  data  entry /display  tasks,  as  shown  in  Tables  17  and  18 
The  derivations  of  the  remaining  R controller  task  allocations  in  Tables 
15,  16,  17,  and  18  are  the  same  as  under  the  ARTS  III  Base  System. 

Thp  rf»siilting  R controller  routine  event  minimum  perfor- 
mance times  for  the  1-man,  1.5-man,  2-man,  and  2.5-man  team  regimes  are 
summarized  in  Table  19. 


2 . ADH  Workload  Weightings 

R controller  routine  workload  weightings  are  calculated  using 
the  routine  event  frequencies  in  Table  1.  The  Table  1 entries  are  based 
on  current  ARTS  III  Base  System  operations  and  are  assumed  to  be  repre- 
sentative of  ADH  operations  since  no  revisions  in  the  frequency  of  routine 
control  requirements  are  anticipated.  We  multiply  the  Table  1 event  fre- 
quencies by  the  corresponding  event  performance  times  in  Table  19  to  ob- 
tain the  R controller  routine  workload  weightings  shown  in  Table  20  for 
each  sector  under  the  four  sector  team  regimes. 

The  R controller  surveillance  workload  weighting  (Table  9)  and 
conflict  workload  weighting  (Table  13)  calculated  for  the  ARTS  III  Base 
System  also  apply  to  the  automated  data  handling  system. 


B . Basic  Metering  and  Spacing  (System  3) 

Basic  metering  and  spacing  (M&S)  is  a terminal  ATC  computerized  op- 
eration to  maximize  runway  system  utilization  by  precisely  controlling 
the  delivery  time  of  arrival  aircraft  to  a runway  system's  threshold  and 

7 

thereby  minimizing  interarrival  times.  The  computer  operation  processes 
FDP-  and  radar-derived  aircraft  situation  data,  determines  sequencing  and 
spacing  requirements  along  the  inbound  routes,  and  displays  control  ma- 
neuver suggestions  to  the  controllers.  Final  decisions  regarding  minute- 
by-minute  control  instructions,  as  well  as  their  actual  issuance  via  A/G 
communications,  are  the  responsibility  of  the  R controllers.  The  control- 
lers manage  the  computerized  operation  by  manually  specifying  algorithm 
parameters  describing  operational  or  procedural  constraints  (i.e.,  in-trail 
separation,  altitude,  speed,  and  route-merging  requirements,  runway  usage, 

7 

restrictions,  and  so  forth) . 

Basic  metering  and  spacing  is  intended  to  replace  part  of  the  deci- 
sion making  involved  in  merging  aircraft  from  divergent  directions  into 
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Tabic  19 
R Controller 


roi:tint-:  event  minimum  performanxe  time  estimates 

OAKLAND  BAY  TRACON 
SYSTEM  2— AUTOMATED  DATA  HANDLING 


Event 

Function 


Routine  Control  Event  D^sicription 


jnt  I baste  Event  and 


Sup;‘letp.ental  Event 


I 

Performance  Time  by  Team  (man-sec/event)  | 
,0-Man  T~  1.5-Man  ! 2.0-Man  I 2.5-Man 


iControl  iHandoff  acceptance 

‘jurisdiction  Manual  acceptance-silent 
transfer  Tower  departure  call 

Controller  coordination 

I Handoff  initiation-silent 

Controller  coordination 


Initial  pilot  call-in 
TCA  clearance  request 

Initial  controller  response 
Altitude  instruction 
Data  update 

Heading/route  instruction 
Speed  instruction 
Approach/runway  advisory 
PVD  display  update 
Traffic  advisory 
ATIS  advisory 
Altimeter  setting  advisory 
Transponder  code  assignment 
Controller  coordinatioa 

Altitude  instruction 
Data  update 

Controller  coordination 

Ueading/route  instruction 
Controller  coordination 

Speed  Instruction 

Approach  clearance 

Runway  assignment 

Traffic  advisory 

Pilot  altitude  report 

Pilot  headlng/position  report 

Pilot  speed  report 

Miscellaneous  A/G  communication 

frequency  change 

Transponder  code  change 
Approach/runway  advisory 


Altitude  revision 

Controller  coordination 

Route/heading  revision 
Controller  coordination 

Miscellaneous  pilot  request 


Pointout  acceptance 
Pointout  initiation 
Control  Instruction  approval 
Plarniag  advisory 
Aircraft  status  advisory 


coordination 


jCeneral 
;sy9teoi 
, operation 


Table  20 


R CONTROLLER  ROUTINE  WORKLOAD  WEIGHTINGS 
OAKLAND  BAY  TRACON,  SYSTEM  2~AUT0MATED  DATA  HANDLING 


Sector 

F - ■ - ■ 

R Controller  Routine  Workload  Weighting, 
kj,  by  Team  (man-sec/aircraft) 

1-Man 

Team 

1 . 5 -Man 

Team 

2 -Man 

Team 

2 . 5-Man 

Team 

AR-1,  Wood side  Final 

53 

50 

49 

46 

AR-2,  Foster  Final 

44 

42 

41 

39 

AR-9,  South  Feeder 

44 

41 

37 

32 

AR-10,  North  Feeder 

43 

40 

37 

31 

DR-1,  Sutro  Departure 

46 

41 

38 

38 

DR-2,  Richmond  Departure 

57 

53 

50 

A7 

one  or  more  final  approach  sequences  and  defining  their  order  or  sequence 
on  a time -integrated  basis.  The  computer  algorithm  must  meter  the  flow 
of  aircraft  across  the  various  merge  points  and  allow  for  the  longitudinal 
spacing  of  aircraft  along  the  routes  through  these  merge  points.  However, 
the  basic  metering  and  spacing  algorithm  determines  sequencing  and  spacing 
requirements  for  aircraft  destined  to  a specific  runway  complex,  and  it 
may  not  encode  knowledge  of  all  aircraft  in  the  sectors.  Therefore,  con- 
trollers must  constantly  compare  the  displayed  instructions  against  their 
own  detailed  minute-by-minute  mental  projections  of  aircraft  trajectories 
in  order  to  satisfy  separation  assurance  needs.  Accordingly,  the  R con- 
troller may  issue  A/G  directives  that  to  do  necessarily  correspond  to 
those  that  are  automatically  generated. 

The  potential  incompatibility  between  actual  and  automatically  gen- 
erated control  instruction  suggests  that  the  basic  metering  and  spacing 
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operation  (i.e.,  without  comprehensive  automated  conflict  processing)  could 
not  be  expected  to  fully  automate  the  decision-making  activities  needed 
in  spacing  aircraft  arrival  traffic.  But  regardless  of  the  content  of 
the  automatically  generated  commands,  the  automated  operation  could  de- 
termine the  sequencing  requirements  needed  to  optimize  runway  utilization, 
display  to  controllers  the  order  in  which  successive  aircraft  are  to  be 
processed  through  merge  points,  and  update  the  sequence  orderings  as 
traffic  situations  change.  This  updating  function  includes  the  ability 
to  automatically  detect  sequencing  incompatibilities  as  they  develop. 
Therefore,  the  basic  metering  and  spacing  operation  is  capable  of  allevi- 
ating some  of  the  decision  making  needed  to  structure  and  update  the  se- 
quencing plan,  although  controllers  must  still  decide  the  minute-by- 
minute  instructions  needed  to  effect  the  preferred  sequences  and  maintain 
spacing.  Such  control  instructions  may  correspond  to  or  be  partly  based 
on  commands  suggested  by  the  automated  operation. 

In  the  following  paragraphs,  we  develop  an  R controller  workload 
model  corresponding  to  our  operational  description  of  basic  metering  and 
spacing.  We  assume  that  controllers  will  respond  to  sequencing  directives 
automatically  issued  and  updated  by  the  computerized  system,  will  mentally 
determine  action  requirements,  and  will  transact  the  A/G  voice  communica- 
tions to  resolve  the  situation. 


1.  M&S  Workload  Model 


Since  controller  sequencing  operations  are  generated  by  pairwise 
interactions  between  merging  aircraft,  basic  metering  and  spacing  will 
alter  the  decision-making  task  times  that  we  have  incorporated  into  our 
conflict  work  model.  We  expect  no  impact  on  routine  or  surveillance  work 
requirements . 


a . Composite  Team  Conflict  Tasks 

Our  projections  of  the  effect  of  basic  metering  and  spacing 
on  the  composite  team's  potential  conflict  processing  task  times  are 
summarized  in  Table  21.  Since  the  computerized  operation  is  designed  to 
facilitate  only  arrival  traffic  flows,  we  assume  that  task  time  reductions 
will  be  experienced  for  local  merging,  overtaking,  and  coordinated  approach 
merging  situations  along  inbound  routes  in  feeder  and  final  sectors;  de- 
parture sectors  will  not  be  affected.  We  assume  no  effect  on  crossing 
conflict  task  performance  because  such  conflicts  are  not  normally  part 
of  the  arrival  traffic  merging  operation.  Since  the  automated  operation 
does  not  completely  alleviate  the  controller's  need  to  decide  on  appropriate 
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Table  21 


ARRIVAL  SECTOR  COMPOSITE  TEAM 
CONFLICT  EVENT  PERFORMANCE  TIME  ESTIMATES 
OAKLAND  BAY  TRACON,  SYSTEM  3— BASIC  METERING  AND  SPACING 


Minimum  Performance  Time  by  Task 
(man-sec/conf llct) 

Conflict 

Event 

1 

Detection 
and  Assessment 

Coordination 

Resolution 

Total 

Crossing 

20 

0 

20 

! 

40 

Local 

Merging 

10  (20) 

0 

15 

25 

(35) 

Overtaking 

10  (20) 

0 

i 

10 

20 

(30) 

Coordinated 

Approach 

Merging 

10  (20) 

» . . , ^ 

5 

- - - 1 

15 

30 

(40) 

System  2 task  times  are  indicated  in  parentheses.  Revisions  apply  only 
to  arrival  (feeder  and  final)  sectors. 


control  instructions,  we  assume  the  detection  and  assessment  task  time  for 
the  three  conflict  situations  of  interest  will  be  reduced  from  20  to  10 
man-sec/conflict.  This  reduction  in  man-sec/conflict  is  due  to  the  as- 
sistance given  to  controllers  by  the  automa t ic  detection  of  sequencing 
conflicts  and  the  automatic  suggestion  of  aircraft  orderings.  With  this 
automation,  controllers  do  not  have  to  spend  time  searching  for  a specific 
pairwise  conflict  and  then  determining  which  aircraft  should  be  merged 
ahead  of  another,  but  must  only  decide  how  to  accomplish  the  merge. 

In  overtaking  situations,  more  time  is  normally  required 
for  mentally  detecting  the  problem  than  with  a merging  conflict,  but  the 
sequencing  decision  here  is  obvious.  Therefore,  a 10  man-sec/event  time 
reduction  results  from  the  automatic  detection  of  the  overtaking  conflict. 
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We  assume  that  automatic  detection  and  assessment  of  overtaking  situations 
is  incorporated  into  the  basic  metering  and  spacing  operation  because  all 
pairs  of  successive  aircraft  must  be  properly  spaced  at  the  runway  thresh- 
old whether  or  not  each  aircraft  is  on  identical  or  merging  inbound  rout- 
ings . 


We  do  not  adjust  conflict  coordination  and  resolution  task 
times  because  basic  metering  and  spacing  is  not  expected  to  affect  the 
communication  activities  necessary  for  these  tasks. 


b.  R Controller  Conflict  Tasks 


As  in  the  case  of  our  analysis  of  the  ARTS  III  Base  System, 
we  assume  the  tasks  represented  in  Table  21  for  crossing,  local  merging, 
and  overtaking  situations  are  performed  by  the  R controller.  The  impact 
of  basic  M6cS  on  the  R controller's  coordinated  approach  merging  tasks  are 
shown  in  Table  22.  The  detection  and  assessment  task  time  reductions  at- 
tributed to  basic  metering  and  spacing  offset  much  of  task  support  that 
otherwise  would  have  been  provided  by  the  coordinator.  That  is,  metering 
and  spacing  essentially  automates  the  sequencing  decisions  made  by  the 
coordinator.  However,  the  coordinator  still  reduces  the  R controller's 
coordination  time  required  to  confirm  sequencing  plans  between  feeder 
sectors,  although  only  by  2 man-sec/event  (and  the  coordinator  is  still 
needed  to  support  R controller  routine  work  requirements  as  defined  in 
the  ARTS  III  Base  System) . 

To  summarize  the  effects  of  basic  metering  and  spacing 
upon  our  workload  model,  the  R controller's  potential  conflict  event  per- 
formance times  (tg,  tin,  respectively)  for  crossing,  local 

merging,  overtaking,  and  coordinated  approach  merging  situations  measured 
in  man-sec/event  are: 


= 40, 

for 

l-man, 

1 . 5 -man. 

2-man, 

and 

2 . 5-man 

teams ; 

tm 

= 25, 

for 

1-man, 

1 . 5-man, 

2-man, 

and 

2 . 5-man 

teams ; 

= 20, 

for 

1-man, 

1 . 5-man, 

2-man, 

and 

2 . 5-man 

teams ; 

tg  = 22.5,  for  1-man  and  2-man  teams, 

= 20.5,  for  1.5-man  and  2.5-man  teams. 


2 . M&S  Workload  Weightings 

No  revisions  to  frequency  of  conflict  events  are  associated  with 
basic  metering  and  spacing,  and  the  conflict  event  frequencies  in  Table  10 


85 


Table  22 


COORDINATED  APPROACH  MERGING 
R CONTROLLER  CONFLICT  EVENT  PERFORMANCE  TIME  ESTIMATES 
OAKLAND  BAY  TRACON,  SYSTEM  3— BASIC  METERING  AND  SPACING 


Sector 

Operation 

* 

R Controller  Minimum  Performance  Time  by  Task 
(man-sec /coordinated  merging  event) 

Detection 
and  Assessment 

Coord ination 

Resolution 

Total 

Average 

Without 

Coordinator  ^ 

AR-9  (or  -10) 

AR-10  (or  -9) 

10  (20) 

10  (20) 

5 

5 

15 

0 

30  (40) 

15  (25) 

22.5(32.5) 



With  ^ 

Coord inator 

AR-9  (or  -10) 

AR-10  (or  -9) 

10 

10 

3 

3 

15 

0 

28 

13 

20.5 

System  2 task  times  are  indicated  in  parentheses. 
^ 1-man  and  2-man  sector  team  manning  regimes 
* 1.5-man  and  2.5-man  sector  team  manning  regimes 
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calculated  for  the  current  ARTS  III  Base  System  apply;  these  frequencies 
also  apply  to  the  automated  data  handling  system  which  we  assume  to  pre- 
cede the  basic  metering  and  spacing  system.  We  multiply  the  conflict 
event  performance  times  (see  above)  by  the  corresponding  Table  10  event 
frequencies  to  obtain  the  R controller  conflict  workload  weightings  shown 
in  Table  23  for  basic  metering  and  spacing. 

The  R controller  routine  workload  weightings  (Table  20)  and  sur- 
veillance workload  weightings  (Table  19)  corresponding  to  the  predecessor 
systems  also  apply  to  the  basic  metering  and  spacing  system. 


C . Conflict  Probe  (System  4) 

Projections  of  aircraft  flight  trajectories  by  computer  calculations 
of  the  FDP  and  radar-derived  situation  data  might  be  used  in  two  ways  to 
assist  controllers  in  processing  potential  conflict  situations;  first, 
to  alert  controllers  of  imminent  potential  conflicts  and  to  suggest  cor- 
rective actions;  second,  to  probe  for  conflicts  over  a long-term  horizon 
to  enable  early  resolution.  In  either  case,  A/G  communications  are  re- 
quired to  transmit  control  instructions. 

The  current  enroute  ATC  conflict  alert  device  provides  warning  of 
an  imminent  potential  conflict  that  occasionally  may  be  missed  by  the  con- 
trollers. It  does  not  affect  the  routine  sector  control  workload  because 
the  conflict  alert  projects  minimum  separation  violation  a few  minutes  or 
less  ahead  of  its  occurrence,  while  the  controller  generally  projects 
conflicts  further  ahead  in  time.  We  will  not  examine  this  device  further 
with  regard  to  terminal  ATL  workload  impact,  although  safety  is  the  area 
of  benefit  potential. 

A conflict  probe  with  longer  look-ahead  capabilities  is  difficult 
to  assess.  To  avoid  excessive  "false  alarms,"  a degree  of  flight  plan 
description  that  is  not  currently  part  of  the  computerized  data-files 
may  be  required.  The  projection  of  the  minute-by-minute  variation  in 
aircraft  trajectories,  which  are  grasped  by  controllers  for  short-term 
projection  purposes,  would  need  to  be  incorporated  into  a conflict  probe 
device.  This  capability  is  particularly  critical  in  a terminal  ATC  en- 
vironment such  as  that  of  the  Bay  TRACON,  in  which  merging  traffic  flows 
are  a major  part  of  basic  operational  procedures,  or  in  any  high-density 
traffic  operation  in  which  turning  maneuvers  are  standard. 

Since  the  computerized  conflict  probe  must  be  knowledgeable  of  the 
flight  trajectories  routinely  followed  by  aircraft  in  the  terminal  air- 
space, a rather  extensive  description  of  the  operational  route  geometries 
and  procedural  restrictions  needs  to  be  incorporated  into  the  probe.  This 
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R CONTROLLER  CONFLICT  WORKLOAD  WEIGHTING 
OAKLAND  BAY  TRACON,  SYSTEM  3— BASIC  METERING  AND  SPACING 
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Indicated  crossing,  local  merging  and  overtaking  conflict  workload  weightings 
2-man,  and  2.5-man  sector  team  manning  regimes. 


knowledge  is  essential  to  enable  projection  of  conflicts  along  the  curved 
and  straight-line  flight  paths,  which  may  be  in  descending,  ascending,  or 
horizontal  configurations  with  speed  or  altitude  restrictions  in  effect. 
The  complexity  and  scope  of  the  route  geometry  and  procedural  data  encoded 
into  the  probe's  software  may  restrict  the  conflict  prediction  capability 
to  that  of  a sector-specific  projection  horizon.  A longer  look-ahead  hor- 
izon over  an  integrated  multisector  routing  environment  may  not  prove  fea- 
sible because  of  data  processing  constraints  and  prediction  inaccuracies 
(i.e.,  excessive  false  alarms). 

Operationally,  a sector  conflict  probe  may  be  used  for  automatically 
assessing  clearance  decisions  Immediately  when  aircraft  enter  into  a sec- 
tor and  for  updating  these  assessments  continuously  until  the  aircraft 
exit.  The  probe  warns  controllers  of  potential  conflicts  projected  within 
a sector  and  may  display  resolution  alternatives.  The  automated  operation 
could  be  integrated  with  basic  metering  and  spacing  to  facilitate  compat- 
ibility between  approach  sequencing  and  spacing  requirements  and  each 
sector's  separation  assurance  responsibilities.  The  integration  of  the 
two  systems  would  enhance  the  validity  of  the  basic  metering  and  spacing 
operation  as  a mechanism  for  automatically  generating  spacing  commands 
acceptable  to  controllers.  (Recall  that  we  assume  that  basic  metering 
and  spacing  is  useful  for  automatically  generating  sequencing  plans,  but 
lacks  the  resolution  needed  to  automatically  generate  reliable  spacing 
commands .) 

Controller  acceptance  of  the  automatically  generated  conflict  avoid- 
ance data  depends  on  the  accuracy  history  of  the  probe  and  on  controllers' 
ability  to  quickly  integrate  the  probe's  conclusions  with  their  own  mental 
comprehension  of  traffic  situations.  The  probe  would  be  of  limited  value 
in  terms  of  workload  reduction  if  the  controllers  duplicated  the  automatic 
conflict  processing  activities.  Questions  concerning  the  realistic  limits 
on  interfacing  computer-derived  control  decisions  with  human  cognitive 
processes  is  beyond  the  scope  of  this  work,  and  for  the  purpose  of  our 
analyses,  we  assume  that  a conflict  probe  is  operationally  feasible.  We 
make  this  assumption  with  the  understanding  that  the  technological  ability 
of  a conflict  probe  to  perform  accurately  and  its  acceptance  by  control- 
lers are  not  yet  proven  or  disproven. 


1 . Conf 1 ict  Probe  Workload  Model 


The  sector  conflict  probe  will  alter  the  sector  teams  task  per- 
formance time  requirements  that  we  have  included  as  part  of  our  conflict 
work  model.  We  foresee  no  impact  on  our  routine  work  or  PVD  surveillance 
work  models . 
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a . Composite  Team  Conflict  Tasks 

The  sector  conflict  probe's  effects  on  composite  team  task 
performance  times  are  estimated  as  shown  in  Table  24  for  all  sectors.  De- 
tection and  assessment  are  performed  by  the  computerized  probe,  and  reso- 
lution suggestions  are  displayed  to  controllers.  We  judge  that  5 man-sec 


Table  24 
COMPOSITE  TEAM 

CONFLICT  EVENT  PERFORMANCE  TIME  ESTIMATES 
OAKLAND  BAY  TRACON,  SYSTEM  4— SECTOR  CONFLICT  PROBE 


Conflict 

Event 

Minimum  Performance  Time  by  Task 
(Man-Sec /Conflict) * 

Detection 
and  Assessment 

Coordination 

Resolution 

Total 

Crossing 

5(20) 

20 

25(40) 

Local  Merging 

5(10) 

0 

15 

20(25) 

Overtaking 

5(10) 

0 

10 

15(20) 

Coordinated 

Approach 

Merging 

5(10) 

5 

15 

25(30) 

System  3 performance  times  are  indicated  in  parentheses.  j 
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will  be  sufficient  to  assimilate 
operations,  actual  resolution  is 
reduction  of  15  man-sec  in  total 


this  information.  Similar  to  current 
performed  via  A/G  communications.  A 
conflict  processing  time  results. 


b.  R Controller  Conflict  Tasks 


We  allocate  the  composite  team  tasks  to  the  R controller 
in  the  manner  described  for  the  predecessor  basic  metering  and  spacing 
system  (and  the  same  as  for  the  ARTS  III  Base  System).  The  R controller's 
potential  conflict  event  performance  times  (t^.,  tjj^,  tg,  and  tg,  respec- 
tively) for  crossing,  local  merging,  overtaking,  and  approach  merging 
situations  measured  in  man-sec/conflict  are: 

t^  = 25,  for  1-man,  1.5-man,  2-man,  and  2.5-man  teams; 

tj„  = 20,  for  1-man,  1.5-man,  2-man,  and  2.5-man  teams; 

to  = 15,  for  1-man,  1.5-man,  2-man,  and  2.5-man  teams; 

tg  = 17.5,  for  1-man  and  2-man  teams, 

= 15.5,  for  1.5-man  and  2.5-man  teams. 

As  in  the  case  of  basic  metering  and  spacing,  the  conflict 
probe  automates  much  of  the  support  work  of  the  coordinator.  The  coor- 
dinator reduces  the  R controller's  coordinated  approach  merging  event  time 
by  only  2 man-sec  (although  other  R controller  work  reductions  are  attri- 
buted to  the  coordinator  in  the  routine  work  model). 


2 . Conflict  Probe  Workload  Weightings 

Since  the  sector  conflict  probe  does  not  affect  the  frequency 
of  potential  conflict  events,  the  event  frequencies  used  to  model  the 
predecessor  basic  metering  and  spacing  system  apply.  These  frequencies 
are  shown  in  Table  10.  We  multiply  the  Table  10  event  frequencies  by  the 
appropriate  event  performance  (see  above)  to  obtain  the  conflict  workload 
weightings  shown  in  Table  25. 

The  R controller  routine  workload  weightings  (Table  20)  and  sur- 
veillance work  weightings  (Table  9)  used  under  the  predecessor  system  also 
apply  to  sector  conflict  probe  system. 
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D . Area  NavlRation  (System  5) 


RNAV  incorporates  navigation  devices  to  achieve  closely  spaced  ar- 
rival and  departure  and  multi-lane  direct  routes  for  high-density  terminal 
and  enroute  airspace.  Enroute  airspace  uses  are  not  considered  here.  The 
concept  we  consider  includes  the  establishment  of  an  RNAV  route  system 
using  fixed  waypoints  to  facilitate  computerized  navigation. 


The  RNAV  waypoint  network  could  be  configured  to  conform  closely  to 
traffic  routing  patterns.  Since  analogous  NAVAID  locations  are  currently 
in  effect,  the  number  of  routine  instructions  required  to  clear  aircraft 
through  the  navigation  network  should  not  be  significantly  reduced.  Use 
of  RNAV  to  reduce  crossing  conflict  resolution  A/G  instructions  may  not 
be  feasible  because  of  the  difficulty  of  integrating  vectoring  maneuvers 
with  an  established  waypoint  network;  it  might  be  as  difficult  to  vector 
the  aircraft  as  it  is  to  establish  and  transmit  temporary  waypoint  fixes 
(e.g.,  latitude  and  longitude)  to  the  pilot. 


The  main  workload-related  benefit  of  terminal  RNAV  appears  to  be  the 
ability  to  reduce  overtaking  conflicts  by  establishing  closely  spaced 
parallel  routes.  By  assigning  successive  aircraft  to  offset  routes  or 
segregating  variable  speed  traffic  onto  the  separate  lanes,  controllers 

7 

could  eliminate  aircraft  overtaking  situations.  However,  we  suggest 
that  this  RNAV  advantage  would  probably  not  be  realized  in  arrival  sec- 
tors where  convergent  routings  dominate  operations  and  where  spacing  must 
be  maintained  to  facilitate  merging  at  final  approach;  overtakings  and 
passings  would  not  routinely  be  permitted  even  though  arrival  aircraft 
are  on  parallel  offset  routes.  Overtakings  and  passings  in  closely  spaced 
parallel  routes  through  departure  sectors  does  appear  feasible  since  the 
route  corridors  are  diverging  and  requirements  to  satisfy  metering  and 
spacing  specifications  do  not  exist. 


1.  RNAV  Workload  Model 


RNAV  will  alter  a portion  of  the  event  frequency  data  that  we 
have  included  as  part  of  our  conflict  model.  We  project  no  impact  on  our 
routine  or  surveillance  work  models. 

We  assume  RNAV  will  eliminate  the  occurrence  of  overtaking  con- 
flicts in  departure  sectors,  as  shown  in  Table  26.  The  Table  26  entries 
are  obtained  by  adjusting  the  conflict  event  frequency  entries  in  Table  10 
which  we  used  to  model  the  predecessor  sector  conflict  probe  system.  We 
assume  RNAV  will  not  eliminate  or  reduce  conflict  event  occurrences  in  the 
arrival  sectors  nor  will  it  eliminate  or  reduce  crossing  and  merging  con- 
flict occurrences  in  the  departure  sectors. 
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Table  26 


CONFLICT  EVENT  FREQUENCY  ESTIMATES 
OAKLAND  BAY  TRACON,  SYSTEM  5 - RNAV 


Conflict  Event 

^ * 

Frequency  Factor 

{ (Conflicts/Hr) 

/ (Aircraft/Hr) 

Visual  Approach  Operations 

Sector 

Crossing,  e^ 

Local 
Merging,  e 

ID 

Overtaking, e 

Coordinated 
Approach  Merging,  e 

a 

AR-1, 

Woodslde  Final 

0 

0 

F 1 

6.5  X 10”^ 

0 

AR-2, 

Foster  Final 

0 

3.2  X 10"^ 

10.6  X 10"^ 

0 

AR-9, 

South  Feeder 

0 

4.6  X 10"^ 

1.4  X 10"^ 

0 

AR-10, 

North  Feeder 

1.5  X 10“^ 

3.3  X 10“^ 

3.7  X 10~^ 

0 

DR-1, 

Sutro  Departure 

5.7  X 10"^ 

0.7  X 10“^ 

0(2.3  X lO"^) 

0 

DR- 2, 

Richmond  Departure 

4.5  X 10"^ 

0 

0(0.8  X 10“^) 



0 

Instrument  Approach  Operations 

Sector 

Crossing, e^ 

Local 
Merging,  e 

ID 

Over taking,  e^ 

Coordinated 
Approach  Merging,  e 

a 

AR-1, 

Woodslde  Final 

0 

0 

13.0  X 10"^ 

0 

AR-2, 

Foster  Final 

0 

3.2  X 10“^ 

21.2  X lO"^ 

0 

AR-9, 

South  Feeder 

0 

4.6  X 10"^ 

2.8  X 10“^ 

3.8  X 10"^ 

AR-10, 

North  Feeder 

1.5  X lO"^ 

3.3  X 10"^ 

7.4  X 10“^ 

3.8  X lO"^ 

DR-1, 

Sutro  Departure 

5.7  X 10“^ 

0.7  X 10“^ 

0(2.3  X 10"^) 

0 

DR-2, 

Richmond  Departure 

4.5  X 10“^ 

0 

0(0.8  X 10“^  ) 

0 

System  4 event  frequencies  are  indicated  in  parenthesis. 


2 . RNAV  Workload  Weightings 

RNAV  does  not  affect  the  conflict  event  performance  times  calcu- 
lated for  the  predecessor  system  (Table  24).  R controller  conflict  work- 
load weighting  may  be  obtained  by  multiplying  these  task  performance  times 
by  the  RNAV  conflict  event  frequencies  in  Table  26.  The  results  are  iden- 
tical to  the  workload  weightings  shown  in  Table  25,  except  that  the  four 
entries  shown  for  departure  sector  overtakings  are  equal  to  zero. 

The  R controller  routine  workload  weightings  (Table  20)  and  sur- 
veillance workload  weighting  (Table  9)  used  for  the  predecessor  system 
also  apply  to  the  RNAV  system. 

E . DABS  Data  Link  (System  6) 

The  DABS  data  link  transmits  digital  data  to  pilots,  including  gen- 

7 

eral  control  instructions  and  collision  avoidance  directives.  It  is  not 
intended  to  transmit  extensive  nonstandard  messages  in  a high-density  en- 
vironment . 

The  data  link  integrated  with  extensive  computerization  is  the  basis 
for  the  so-called  "control-by-exception"  concept.  We  view  this  concept 
as  somewhat  more  revolutionary  than  evolutionary,  since  it  would  transform 
the  controller  into  a systems  manager  who  is  not  routinely  engaged  in 
minute-by-minute  tactical  decision  making.  Rather,  he  would  monitor  and 
regulate  a computerized  sector  control  operation;  the  latter  would  auto- 
matically issue,  by  means  of  data  link,  many  routine  and  conflict  process- 
ing clearances  and  instructions  according  to  traffic  situations  and  pro- 
cedural rules.  The  controller  would  intervene  when  necessary  to  adjust 
procedural  rules,  to  respond  to  pilot  requests,  to  resolve  non-standard 
situations,  and  to  transmit  A/G  messages  that  are  too  long  for  the  DABS 
data  link.  In  essence,  he  would  concentrate  on  minute-by-minute  proce- 
dural decision  making  and  perform  minute-by-minute  tactical  decision  mak- 
ing only  when  required.  We  assume  that  sectors  will  be  retained  as  the 
basic  control  jurisdictional  unit  to  provide  fault  tolerance  in  the  event 
of  data  link  or  computer  system  malfunction  (where  operations  fall  back 
to  a nondata -link  ATC  system) . 

Under  the  control-by-exception  concept,  we  assume  that  a sector  con- 
troller need  not  review  and  approve  each  Instruction.  If  he  were  required 
to  read,  mentally  assimilate,  and  approve  each  instruction  (duplicating 
the  automated  operation),  workload  advantages  would  not  be  realized.  This 
concept  assumes  the  implementation  of  refined  and  advanced  metering  and 
spacing  (which  extend  basic  metering  and  spacing  services  to  integrated 
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multi-airport  arrival  and  departure  operations)  and  automatic  conflict 
processing  computerization,  using  data  link  to  deliver  situation  resolu- 
tion instructions.  By  this  means,  sequencing,  spacing,  and  potential 
conflict  situations  are  resolved  without  dependence  on  human  decision 
making.  However,  assuming  human  controllers  retain  responsibility  for 
separation  assurance,  the  question  arises  as  to  the  degree  to  which  con- 
trollers would  actually  remove  themselves  from  the  capability  to  perform 
minute-by-minute  tactical  decision  making.  Therefore,  we  assume  that 
controllers  will  continue  to  perform  intensive  PVD  surveillance  to  retain 
real-time  mental  picture-keeping  (which  would  be  vital  in  the  event  of 
some  computer-processing  failures)  and  to  maintain  cognizance  of  computer- 
generated traffic  structuring  and  conflict  processing  strategies. 


1.  Data  Link  Workload  Model 


The  data  link-based  control-by -exception  operation  will  alter 
many  of  the  sector  team's  communication  and  data  maintenance  activities 
that  we  have  included  as  part  of  our  routine  and  conflict  work  models. 
We  foresee  no  impact  on  our  surveillance  work  model.  In  the  following 
paragraphs  we  adjust  our  routine  and  conflict  work  models  to  represent 
control-by-exception  operations  under  the  assumption  that  all  aircraft 
are  equipped  with  DABS  data  link. 


a.  Routine  Work 


Composite  Team  Routine  Tasks--Our  revisions  to  the  route 
task  performance  times  for  the  composite  team  are  shown  in  Table  27. 

The  parentheses  enclose  task  time  entries  that  apply  to  the  predecessor 
RNAV  system  (which  were  originally  established  as  part  of  the  ADH  system 
routine  work  model  and  presented  in  Table  14) . 

With  reference  to  task  time  revisions  in  Table  27,  we  as- 
sume the  control-by-exception  computerization  performs  much  of  the  me- 
chanical data  maintenance  activities  associated  with  the  assimilation 
and  updating  of  traffic  control  operations  data.  Controllers  need  not 
perform  the  2 man-sec  keyboard  manual  silent  handoff  acceptance  because 
the  computerization  will  automatically  begin  to  process  control  refine- 
ments . 


A/G  voice  communications  for  the  standard  altitude,  head- 
ing, speed,  approach  and  runway  advisory,  transponder  code  change,  and 
frequency  change  instructions  are  assumed  to  be  replaced  by  data  link 
transmissions.  These  automatic  transmissions  eliminate  controller  time 


Table  27 
COMPOSITE  TEAM 

ROUTINE  EVENT  MINIMUM  PERFORMANCE  TIME  ESTIMATES 
OAKLAND  BAY  TRACON,  SYSTEM  6— DABS  DATA  LINK 


Event 

Function 


Routine  Control  Event  Description 


Perfomance  Tine  by  Task  (nan*>sec/event)* 


Basic  Event  and 
Supplemental  Event 


a/ G Com~ 

munlca- 

tion 


1 Handoff  acceptance 

ictlon  Manual  acceptance-silent 
er  Tower  departure  call 

Controller  coordination 

Handoff  initiation-silent 
Controller  coordination 


Initial  pilot  call-in 
TCA  clearance  request 

Initial  controller  response 
Altitude  instruction 
Data  update 

Heading/route  instruction 
Speed  instruction 
Approach/runway  advisory 
PVD  display  update 
Traffic  advisory 
ATIS  advisory 
Altimeter  setting  advisory 
Transponder  code  assignment 
Controller  coordination 

Altitude  instruction 
Data  update 

Controller  coordination 

Reading/route  Instruction 
Controller  coordination 

Speed  instruction 

Approach  clearance 

Runway  assignment 

Traffic  advisory 

Pilot  altitude  report 

Pilot  heading/position  report 

Pilot  speed  report 

Miscellaneous  A/G  comnunication 

Frequency  change 

Transponder  code  change 
Approach/runway  advisory 


Altitude  revision 

Controller  coordination 

Route/heading  revision 
Controller  coordination 

Miscellaneous  pilot  request 


Pointout  acceptance 
Pointout  initiation 
Control  instruction  approval 
planning  advisory 
Aircraft  status  advisory 


Data  block  forcing/removal 
PVD  display  adjustment 


System  5 perfomance  times  are  indicated  in  parenthesis. 


Operstional  cognizance 
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spent  in  these  A/G  voice  communications.  However,  when  such  activities 
are  nonstandard  and  require  intersector  coordination,  we  assume  that  A/G 
voice  communications  and  manual  keyboard  data  entry/display  operations 
will  be  required.  The  duration  of  each  nonstandard  A/G  communications 
depends  on  the  message  transaction  involved,  and  our  estimate  varies  from 
3 to  5 man-sec,  in  accordance  with  the  communication  time  requirements 
determined  for  the  predecessor  systems.  Similarly,  we  use  3 man-sec  to 
account  for  keyboard  data  entry/display  actions  since  it  is  typical  of 
observed  controller  capabilities.  We  note  that  data  entry/display  opera- 
tions required  for  updating  altitude  and  runway  data  and  changing  trans- 
ponder codes  are  assumed  to  be  performed  automatically,  thus  eliminating 
these  3 in-sec  manual  task  time  requirements. 

Also  shown  in  Table  27  under  the  data  entry/display  heading 
are  "operational  cognizance"  activities.  These  reflect  the  controller 
monitoring  work  required  to  maintain  awareness  of  the  computerized  traffic 
structuring  strategies.  Although  keyboard  activities  are  not  necessarily 
assumed,  these  task  items  provide  a surrogate  mechanism  for  estimating 
the  controller  monitoring  work  associated  with  each  data  link  message 
transmission.  In  actuality,  rather  than  reviewing  each  individual  trans- 
mission, controllers  would  probably  be  provided  with  a data  display  de- 
scribing the  overall  traffic-oriented  procedural  intentions  of  the  com- 
puter operation,  and  thereby  maintain  their  mental  picture  of  control 
operations . 


We  judge  that  3 man-sec  is  a reasonable  time  to  allow  for 
the  operational  cognizance  activities  associated  with  a standard  data 
link  message  transmission  and  pointout  (the  latter  function  would  also 
be  automatically  performed).  This  time  span  is  not  as  long  as  a typical 
A/G  voice  message,  but  should  be  sufficient  for  the  controller  to  recog- 
nize the  procedural  intentions  of  the  computerized  operation.  We  associate 
a 5 man-sec  operation  cognizance  time  with  the  controller's  initial  re- 
sponse to  a pilot  call-in  in  order  to  account  for  the  time  controllers 
need  to  mentally  assimilate  the  aircraft's  operational  requirements  in 
relation  to  the  computerized  procedural  intentions. 

R Controller  Routine  Tasks--We  allocate  the  composite  team 
routine  task  time  requirements  to  the  R controller  for  each  of  the  four 
sector  team  manning  regimes  using  the  same  allocation  guidelines  described 
for  the  ARTS  III  base  and  the  automated  data  handling  system.  Results 
are  presented  in  Tables  28,  29,  30,  and  31. 

The  corresponding  R controller  routine  event  minimum  per- 
formance times  for  the  1-man,  1.5-man,  2-man,  and  2.5-man  team  regimes 
are  summarized  in  Table  32.  We  note  that  no  R controller  event  time 
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R CONTROLLER 

ROUTINE  EVENT  MINIMUM  PERFORMANCE  TIME  ESTIMATES 
OAKLAND  BAY  TRACON,  SYSTEM  6,  1-MAN  TEAM 


Routir.o  Control  Event  Description 


Event 

Function 


Basic  Event  and 
Siippler.ent.al  Event 


Performance  Time  by  Task  (man-sec/event ) 

/G  Data,  Flight  lateF- ~Faii^5^ 
mi.rhi-  Strip  phone  Face 

Process-  Communi-  Comr.uni-  ^ 
tion  ^P5[on  Ing  cation  cation 


jurisdiction'  Manual  acceptance-s ilent 
transfer  ! Tower  departure  call 

j Controller  coordination 

jHandoff  initiation-silent 
I Controller  coordination 


Table  29 


I 


w 


R CONTROLLER 

ROUTINE  EVENT  MINIMUM  PERFORMANCE  TIME  ESTIMATES 
OAKLAND  BAY  TRACON,  SYSTEM  6,  1.5-MAN  TEAM 


Routir.t. 

Control  Event  Desc»'iptioa 

Performance  Time  by  Task  (man-sec/event) 

A/C 

Data . 

Flight 

Inter- 

1 Facc-to- 

Event 

Basic  Event  and 

Communi- 

Strip 

phone 

Communi- 

Face 

Total 

Function 

Supplemental  Event 

cation 

Ing 

cation 

cation 

Control 

Handoff  acceptance 

0 

jurisdiction 

Manual  acccptance-silent 

0 

transfer 

Tower  departure  call 

0 

Controller  coordination 

3 

3 

Handoff  initiation- silent 

1 

Controller  coordination 

3 

3 

Traffic 

Initial  pilot  call-in 

4 

5 

structuring 

TCA  clearance  request 

4 

10 

14 

Initial  controller  response 

2 

5* 

7 

Altitude  inscructioQ 

0 

Data  update 

0 

Heading/route  instruction 

0 

Speed  Instruction 

0 

Approach/runway  advisory 

0 

PVD  display  update 

Traffic  advisory 

3 

3 

ATIS  advisory 

0 

Altimeter  setting  advisory 

0 

Transponder  code  assignment 

3 

3 

Controller  coordination 

3 

3 

Altitude  instruction 

3* 

3 

Data  update 

0 

Controller  coordination 

5 

3 

3 

11 

Heading/ route'  instruction 

3* 

3 

Controller  coordination 

5 

3 

3 

11 

Speed  Instruction 

3* 

3 

Approach  clearance 

3* 

3 

Runway  assignment 

3* 

3 

Traffic  advisory 

5 

5 

Pilot  altitude  report 

5 

5 

Pilot  heading/position  report 

5 

5 

Pilot  speed  report 

5 

5 

Miscellaneous  A/G  communication 

5 

5 

Frequency  change 

3* 

3 

Transponder  code  change 

0 

Approach/ runway  advisory 

0 

Pilot 

Altitude  revision 

6 

3 

9 

request 

Controller  coordination 

3 

3 

Route/heading  revision 

8 

3 

11 

Controller  coordination 

3 

3 

Miscellaneous  pilot  request 

6 

6 

•General 

Polntout  acceptance 

3* 

3 

intersector 

coordination 

Pointout  initiation 

3* 

3 

Control  instruction  approval 

3 

3 

Planning  advisory 

3 

3 

Aircraft  status  advisory 

0 

General 

Data  block  forcing/removal 

3 

3 

system 

joperntion 

PVD  display  adjustment 

3 

3 

100 


♦Operational  cognizance 


Table  30 


R CONTROLLER 

ROUTINE  EVENT  MINIMUM  PERFORMANCE  TIME  ESTIMATES 
OAKLAND  BAY  TRACON,  SYSTEM  6,  2-MAN  TEAM 


RouCir.t 

Control  Event  Description 

Performance  Time  by  Task  (man-sec/event) 

A/G 

..Data  . 

Process- 

ing 

Inter- 

Face-to- 

Event 

Function 

Basic  Event  and 
Supplemental  Event 

Communi- 

cation 

& 

phone 

Communi- 

cation 

Face 

Coitsnunl- 

cation 

Total 

Control 

Handoff  acceptance 

0 

jurisdiction 

Manual  acceptance-silent 

0 

transfer 

Tower  departure  call 

0 

Controller  coordination 

3 

3 

Handoff  initiation-silent 

0 

Controller  coordination 

3 

3 

Traffic 

Initial  pilot  call-in 

4 

1 

structuring 

TCA  clearance  request 

4 

4 

Initial  controller  response 

2 

5* 

Altitude  instruction 

0 

Data  update 

0 

Heading/route  instruction 

0 

Speed  Instruction 

0 

Approach/runway  advisory 

0 

PVD  display  update 

Traffic  advisory 

3 

3 

AXIS  advisory 

0 

Altimeter  setting  advisory 

0 

Transponder  code  assignment 

3 

Controller  coordination 

3 

Altitude  instruction 

3* 

Data  update 

0 

Controller  coordination 

5 

3 

R 

Heading/route  instruction 

3* 

■ 

3 

Controller  coordination 

5 

3 

8 

Speed  instruction 

3* 

3 

Approach  clearance 

3* 

3 

Runway  assignment 

3* 

3 

Traffic  advisory 

5 

5 

Pilot  altitude  report 

mm 

5 

Pilot  heading/position  report 

B 

5 

Pilot  speed  report 

B 

5 

Miscellaneous  A/G  consaunication 

5 

5 

Frequency  change 

3* 

3 

Transponder  code  change 

Approach/runway  advisory 

0 

Pilot 

Altitude  revision 

6 

6 

request 

Controller  coordination 

3 

3 

Route/heading  revision 

8 

3 

8 

Controller  coordination 

Miscellaneous  pilot  request 

6 

B 

Ceneral 

Polntout  acceptance 

3* 

intersector 

coordination 

Pointout  initiation 

3* 

3 

Control  instruction  approval 

3 

3 

Planning  advisory 

3 

3 

Aircraft  status  advisory 

0 

'“eneral 

Data  block  forcinp./removal 

0 

oystcn 
joperiit  ion 

PVD  display  ndjufitment 

0 

♦Operational  cognizance 
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Table  31 


Traffic 

structuring 

Initial  pilot  call-in 

TCA  clearance  request 

j 

Initial  controller  response 
Altitude  instruction 

Data  update 

Heading/route  instruction 
Speed  Instruction 
Approach/runway  advisory 

PVD  display  update 

Traffic  advisory 

ATIS  advisory 

Altimeter  setting  advisory 
Transponder  code  assignment 
Controller  coordination 

Altitude  instruction 

Data  update 

Controller  coordination 

Heading/route  instruction 
Controller  coordination 

i 

Speed  Instruction 

Approach  clearance 

Runvay  assigxuoent 

Traffic  advisory 

Pilot  altitude  report 

Pilot  heading/position  report 

Pilot  speed  report 

Miscellaneous  A/G  coanaunlcation 

1 

Frequency  change 

Transponder  code  change 
Approach/runway  advisory 

Pilot  Altitude  revision 

request  Controller  coordination 

Route/heading  revision 
Controller  coordination 

Miscellaneous  pilot  request 


General  j 
Xntersector  ! 
coordination | 


operation 


jpolntout  acceptance 
Pointout  initiation 
Control  instruction  approval 
Planning  advisory 

Aircraft  status  advisory 

I __ 

'Data  block  forclng/rcmoval 
•PVT)  display  adjustment 


'Operational  cognizance 


Table  32 
R Controller 


ROl’TTNT.  EVENT  MINIMUM  PERFOR>L\NCE  TIME  ESTIM/XTES 

OAKLAND  BAY  TRACON 
SYSTEM  6— DABS  DATA  LINK 


_ - 

Routine 

Control  Event  Description 

Performance  Time  by  Team  (man-sec/event)  | 

Event 

Basic  Event  and 

1 .0-Man 

L . 5-Man 

2,0-Man 

Function 

Supplemental  Event 

Team 

Team 

Team 

Team 

Control 

Handof f acceptance 

0 

0 

0 

jurisdiction 

Manual  acceptance-silent 

0 

0* 

0 

0 

transfer 

Tower  departure  call 

0 

0 

0 

0 

Controller  coordination 

6 

3 

3 

3 

Handoff  initiation-silent 

I 

1 * 

0 

0 

Controller  coordination 

6 

3 

3 

3 

L 

Traffic 

Initial  pilot  call-in 

5 

5 

structuring 

TCA  clearance  request 

14 

8 

Initial  controller  response 

7 

7 

Altitude  instruction 

0 

0 

0 

0 

Data  update 

0 

0 

0 

0 

Heading/route  instruction 

0 

0 

0 

0 

Speed  instruction 

0 

0 

0 

0 

Approach/runway  advisory 

0 

0 

0 

0 

PVD  display  update 

0 

0 

0 

0 

Traffic  advisory 

3 

3 

3 

3 

ATIS  advisory 

0 

0 

0 

0 

Altimeter  setting  advisory 

0 

0 

0 

0 

Transponder  code  assignment 

3 

3 

3 

Controller  coordination 

3 

3 

3 

Altitude  instruction 

3 

3 

3 

Data  update 

0 

0 

0 

0 

Controller  coordination 

13 

11 

8 

8 

Heading/ route  instruction 

3 

3 

3 

3 

Controller  coordination 

13 

11 

8 

8 

Speed  instruction 

3 

3 

3 

3 

Approach  clearance 

3 

3 

3 

3 

Runway  assignment 

3 

3 

3 

3 

Traffic  advisory 

5 

5 

5 

5 

Pilot  altitude  report 

5 

5 

5 

5 

Pilot  heading/position  report 

5 

5 

5 

5 

Pilot  speed  report 

5 

5 

5 

5 

Miscellaneous  A/G  cotomunicatlon 

5 

5 

5 

5 

Frequency  change 

3 

3 

3 

3 

Transponder  code  change 

0 

0 

0 

0 

Approach/runway  advisory 

0 

0 

0 

0 

Pilot 

Altitude  revision 

9 

9 

9 

9 

request 

Controller  coordination 

5 

3 

3 

3 

Route/heading  revision 

11 

11 

11 

11 

Controller  coordination 

5 

3 

3 

3 

Miscellaneous  pilot  request 

6 

b 

6 

6 

General 

Pointout  acceptance 

3 

3 

3 

3 

Intersector 

coordination 

Polntout  initiation 

3 

3 

3 

Control  Instruction  approval 

5 

3 

3 

J 

Planning  advisory 

5 

3 

3 

3 

1 

Aircraft  status  advisory 

5 

n 

0 

0 

'General 

Data  block  forclng/removal 

3 

3 

0 

0 

jsystem 

operation 

PVT)  display  adjustment 

3 

3 

0 



Indicated  event  occurs  at  one'-half  the  rare  sho%m  In  Table  1. 
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reductions  are  obtained  by  increasing  from  2-man  to  2.5-man  team  opera- 
tions. In  the  2-man  regime,  the  H controllers  perform  the  interphone 
communications  and  those  few  data  entry/display  operations  that  are  not 
performed  automatically  by  the  computerized  system.  Therefore,  there 
are  no  additional  tasks  that  may  be  offloaded  effectively  from  the  R 
controller  to  a coordinator  under  the  2.5-man  regime. 


b.  Conflict  Work 


Composite  Team  Conflict  Tasks--Our  revisions  to  the  com- 
posite team  conflict  tasks  performance  times  for  DABS  control-by-exception 
operation  are  shown  in  Table  33.  We  assume  that,  in  accordance  with  their 
separation  assurance  responsibilities,  controller  will  maintain  close 


Table  33 

COMPOSITE  TEAM 

CONFLICT  EVENT  PERFORMANCE  TIME  ESTIMATES 
OAKLAND  BAY  TRACON,  SYSTEM  6 ~ DABS  DATA  LINK 


Conflict 

Minimum  Performance  Time  by  Task* 

(man- sec / conf li ct ) 

Event 

Detection 
and  Assessment 

Coordination 

Resolut ion 

Total 

Crossing 

5 

0 

10+  (20) 

15(25) 

Local 

Merging 

5 

0 

10^(15) 

15(20) 

Overtaking 

5 

0 

lO'^' 

15 

Coordinated 

Merging 

5 

0(5) 

10''’(15) 

15(25) 

System  5 performance  times  are  indicated  in  parentheses. 
Conformance  confirmation 


104 


surveillance  of  conflict  processing  operations.  Since  actual  conflict 
resolution  instructions  would  be  issued  by  data  link,  we  estimate  that 
10  man-sec  in  resolution  time  is  needed  by  controllers  to  confirm  air- 
craft conformance.  This  time  enables  controllers  to  check  aircraft  re- 
sponses to  the  automatically  transmitted  conflict  avoidance  directives. 
Also,  the  computerized  operation  obviates  the  need  for  coordinating  ap- 
proach mergings  between  sector. 

R Controller  Conflict  Tasks--The  R controller  conflict 
event  performance  times  (t^,,  t^^^,  t^,  and  t^,  respectively)  for  crossing 
local  merging,  overtaking,  and  coordinated  approach  merging  situations 
are  identical  to  those  shown  for  the  composite  team  in  Table  33,  all  of 
which  equal  15  man-sec  per  conflict.  In  these  cases,  the  conflict  sup- 
port work  of  the  coordinator  effectively  is  automated  by  the  control-by- 
exception operation. 


2 . Data  Link  Workload  Weightings 

The  R controller  routine  and  conflict  event  frequencies 
used  to  model  the  predecessor  system  apply  to  DABS  data  link  modeling 
since  the  rates  of  occurrence  of  these  events  are  not  affected  by  control- 
by-exception  automation.  We  use  the  appropriate  routine  event  frequencies 
(Table  1)  and  performance  times  (Table  32)  to  calculate  the  routine  work- 
load weighting  summarized  in  Table  34.  The  conflict  event  performance 
times  (Table  33)  and  RNAV-based  conflict  event  frequencies  (Table  26)  are 
used  to  calculate  the  conflict  workload  weightings  shown  in  Table  35. 

The  R controller  surveillance  workload  weightings  (Table  9) 
used  for  the  predecessor  systems  also  apply  to  the  DABS  data  link  system. 

Recall  that  routine  and  conflict  task  time  reductions  could 
not  be  obtained  by  increasing  sector  manning  to  the  2.5-man  level.  The 
routine,  conflict,  and  surveillance  workload  weightings  reflect  these  re- 
sults, indicating  that  simultaneous  use  of  a coordinator  and  H controller 
is  not  an  effective  way  of  operating  control-by-exception. 


F.  DABS  Intermittent  Positive  Control 


IPC  provides  traffic  advisories  and  threat  avoidance  commands  to  VFR 

>7 

pilots  on  an  as-needed  basis.  Extended  to  IFR  operations,  IPC  would  op- 
erate on  imminent  (e.g.,  load-time  of  1 to  2 min)  conflict  situations  that 
are  "missed"  by  controllers.  This  is  assumed  to  be  a safety  enhancement 
device  that  would  not  affect  the  capacity  considerations  associated  with 
normal  sector  task  activities. 
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Tcibl.e  34 


R CONTROLLER  ROUTINE  VWRKLOAD  WEICLTINCS 
OAKLAND  BAY  TRACON,  SYSTEM  6— DABS  DATA  LINK 


Sector 

R Controller  Routine  Workload  Weighting, 
by  Team  (man-sec/aircraft) 

1-Man 

Team 

1 . 5-Man 

Team 

2-Man 

Team 

2.5-Man 

Team 

AR-1,  Woodside  Final 

38 

37 

34 

34 

AR-2,  Foster  Final 

34 

33 

32 

32 

AR-9,  South  Feeder 

28 

26 

23 

23 

AR-IO,  North  Feeder 

30 

28 

23 

23 

DR-1,  Sutro  Departure 

44 

39 

37 

37 

DR-2 , Richmond  Departure 



52 

49 

44 

44 

However,  DABS  IPC  may  be  needed  to  provide  fault  tolerance  in  the 
event  of  failures  in  the  other  enhancement  operations  (particularly  con- 
flict processing  automation).  Therefore,  IPC  would  be  necessary  for  the 
successful  implementation  of  these  other  features.  We  do  not  further 
evaluate  IPC;  it  is  considered  to  be  an  incremental  add-on  to  the  data 
link  system  but  with  no  independent  capacity  impact. 
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Table  35 


Indicated  crossing,  local  merging  and  overtaking  conflict  workload  weightings  are  for  any  of  the  1-man,  1.5-i 
2-iiian,  and  2.5-man  sector  team  manning  regimes. 


VIII  BAY  TRACON  SECTOR  CAPACITY  AND  MANNING 


In  this  section,  we  estimate  traffic  capacities  for  six  Bay  TRACON 
sectors  for  each  sector  team  manning  regime  under  each  of  the  six  ATC 
system  alternatives.  We  use  these  capacities  to  estimate  multisector 
minimum  manning  requirements  for  a range  of  traffic  levels,  which  enable 
comparisons  of  UG3RD  systems  effects  on  facility  operations. 


A.  Sector  Capacity 

Recall  that  we  define  sector  traffic  capacity  as  the  hourly  traffic 
rate  (ac/hr)  that  generates  48  man-min/hr  of  R controller  work.  We  use 
the  routine,  surveillance  and  conflict  workload  weightings  quantified  in 
the  two  preceding  sections  of  this  report  to  calculate  R controller  work- 
load for  successive  increments  in  traffic  flow,  and  interpolate  the  sec- 
tor traffic  capacity. 

We  apply  this  procedure  to  estimate  sector  capacities  for  both 
visual  and  instrument  approach  conditions,  for  each  of  the  four  sector 
team  manning  regimes,  and  for  each  of  the  six  ATC  system  alternatives. 

The  resulting  capacity  estimates  are  presented  in  Tables  36,  37,  38,  39, 
40,  and  41,  respectively,  for  each  of  the  six  sectors  of  interest.  (We 
note  that  these  capacity  estimates  were  judged  to  be  "realistic"  and 
"reasonable"  by  a Bay  TRACON  supervisory  staff  member.) 

These  sector  capacities  directly  reflect  the  R controller  activity 
requirements  defined  by  the  workload  weightings.  We  see  that  feeder  and 
final  sector  capacities  for  instrument  approach  operations  are  less  than 
those  for  visual  operations  because  of  the  additional  approach  merging 
work,  while  departure  sector  capacities  are  not  affected  by  approach 
conditions.  The  sector  capacities  generally  increase  for  each  successive 
increment  in  sector  team  manning  because  the  R controller  usually  off- 
loads some  portion  of  routine  or  conflict  work  to  the  added  team  mem- 
ber(s).  In  some  situations,  the  amount  of  work  offloaded  is  not  suf- 
ficiently significant  to  increase  sector  capacity;  in  the  case  of  2-man 
versus  2.5-man  team  regimes  under  the  DABS  data  link  system,  no  work 
offloading  is  projected  and  sector  capacities  are  identical  under  the 
two  regimes.  Therefore,  the  2-man  team  is  the  practical  sector  manning 
limit  under  System  6 operations. 


PRKfSEIlMO  PAOI  BUMK-MOT  flUaB 
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Table  36 


In-trall  operations  on  parallel  final  approach 


In-trall  operations  on  parallel  final  approach  courses 


SOUTH  FEEDER  (AR-9)  CAPACITY  ESTIMATES 


In-trail  operations  on  parallel  final  approach  courses 


Table  39 


In-trail  operations  on  parallel  final  approach  courses 


SUTRO  DEPARTURE  (DR-1)  CAPACITY  ESTIMATES 


Table  41 


In-trall  operations  on  parallel  final  approach  courses 


Each  UG3RD  ATC  system  successor  to  the  ARTS  III  Base  system  includes 
an  automation  feature  that  is  added  onto  the  operational  features  of  Its 
predecessors.  Since  each  UG3RD  feature  further  reduces  R controller 
workload  requirements  to  varying  extents,  sector  capacity  generally  in- 
creases as  each  successive  system  evolves.  However,  some  of  the  automa- 
tion features  do  not  alleviate  workload  in  certain  operational  environ- 
ments. For  example,  basic  metering  and  spacing  supports  approach 
operations,  but  it  does  not  increase  departure  sector  capacity.  Simi- 
larly, RNAV  was  not  assumed  effective  in  reducing  work  requirements  for 
arrival  operations,  and  it  does  not  increase  feeder  or  final  sector  ca- 
pacity. 

We  note  that  our  workload  analyses  assume  100  percent  deployment  of 
RNAV  and  DABS  data  link  airborne  equipment  for  the  aircraft  fleet  under 
TRACON  control.  We  do  not  explicitly  assess  the  effect  on  capacity  of 
partial  deployment  of  such  avionics  equipment.  However,  based  on  our 
previous  analyses  of  enroute  ATC  aircraft  equipment  deployments,  first- 
cut  capacity  estimates  for  partial  deplo5raient  may  be  made  by  linear 
interpolations  between  systems.  For  example,  a 100  percent  RNAV  and 
50  percent  data-link  aircraft  equipment  deployment  is  expected  to  obtain 
sector  capacity  estimates  midway  between  those  shown  in  Tables  36  through 
41  f'^r  RNAV  and  DABS  data  link. 


B.  Multi-Sector  Manning 

Subject  to  the  traffic  handling  constraints  imposed  by  our  sector 
capacity  calculations,  we  wish  to  compare  the  relative  manning  require- 
ments of  each  of  the  six  alternative  ATC  systems  associated  with  the 
joint  operation  of  the  six  sectors.  These  comparisons  require  estimating 
multi-sector  minimum  manning  over  a range  of  traffic  activity  projections 
so  that  the  relative  effectiveness  of  each  system's  traffic  service  capa- 
bility may  be  assessed.  We  use  sector  capacities  calculated  for  instru- 
ment approach  conditions  rather  than  visual  because  instrument  conditions 
are  more  critical  constraints  to  controller  traffic  handling  capabilities. 


1 . Manning  Calculations 

Our  intention  is  to  calculate  for  each  system  the  minimum  number 
of  manned  control  positions  required  to  process  various  levels  of  traffic 
through  each  sector  without  exceeding  our  R controller  workload-based 
capacity  constraints.  Manning  estimates  might  be  made  simply  by  compar- 
ing the  traffic  through  each  sector  during  some  specific  hour  against  the 
hourly  capacity  of  each  sector  team  manning  regime.  However,  certain 
aspects  of  TRACON  operations  complicate  this  manning  estimation  procedure. 
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The  first  of  these  complicating  factors  is  that  a coordinator 
does  not  support  one  single  sector  team,  but  operates  interactively  with 
two  specific  sector  teams.  Therefore,  we  need  to  account  for  coordinator 
manning  requirements  on  a sector  pairwise  basis,  rather  than  on  an  in- 
dividual sector  basis.  Second,  sector  manning  requirements  are  determined 
by  the  peak  hour  traffic  during  an  8-hour  work  shift.  We  need  to  account 
for  the  peak  hour  manning  needs  even  though  each  sector's  peak  hour  does 
not  necessarily  occur  at  the  same  time  as  another's.  Third,  flight  data 
positions  support  control  operations  even  though  they  are  not  necessarily 
part  of  any  specific  sector  team.  We  need  to  account  for  flight  data 
manning  needs  on  a facility-wide  basis. 

The  estimation  procedure  we  use  to  account  for  these  manning 
needs  is  as  illustrated  in  Tables  42,  43,  44,  45,  46,  and  47  for  the 
six  alternative  ATC  systems,  respectively.  These  tables  are  worksheets 
that  trace  our  calculations. 

Consider  Table  42,  which  represents  the  ARTS  III  Base  system. 

Our  traffic  base  is  the  1975  statistics  reported  for  the  8-hour  day  shift 
for  the  Bay  TRACON  busy  day  (90th  percentile).^  The  traffic  statistics 
shown  in  Table  42  are  the  peak  hour  traffic  counts  for  each  sector.  Our 
sector  capacity  estimates  for  each  team  manning  regime  are  also  listed. 

We  determine  a traffic  handling  growth  potential  factor  (relative  to  the 
1975  day  shift,  peak  hour  traffic)  for  each  sector's  manning  regime  by 
dividing  the  corresponding  sector  traffic  capacity  by  the  peak  hour  traf- 
fic. For  example,  the  1-man  team  regime  for  AR-1  is  shown  to  have  a 
traffic  growth  potential  factor  equal  to  1.37,  which  means  this  sector 
operation  is  assumed  capable  of  handling  a 37  percent  increase  to  the 
1975  day  shift,  peak  hour  traffic. 

We  use  the  traffic  growth  potential  factors  to  estimate  sector 
manning  needs  for  25  percent  increments  in  day-shift  traffic  projections 
As  shown  in  Table  42,  we  compare  each  traffic  factor  increment  against 
a sector's  growth  potential  for  each  team  manning  regime,  and  identify 
the  sector  manning  required  to  handle  the  projected  traffic.  By  this 
means,  we  find  that  AR-1  needs  a 2-man  team  to  handle  a 50  percent  traffic 
Increase,  and  a 2.5-man  team  to  handle  a 75  percent  traffic  increase. 
However,  the  coordinator  in  this  latter  regime  supports  AR-2  as  well  as 
AR-1,  even  though  AR-2  can  handle  the  75  percent  traffic  increase  with 
a 1-man  team.  To  account  for  the  sector  pairwise  services  of  the  coordi- 
nator, we  assign  a 1.5-man  team  to  AR-2  at  this  traffic  level. 

With  reference  to  the  sector  team  manning  acquirement  calculated 
for  the  DABS  data  link  system  in  Table  47,  the  two  final  sectors  are  shown 
not  to  be  manned  at  low  traffic  activity  levels.  In  this  case,  the  large 
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Manning  factor  (1975  Base) 
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Source:  "Application  of  ATt  Terminal  Standard  for  PY  1975."  computer  printout  manuscript,  Air  Traffic  Service,  FAA  (1976) 


traffic  growth  potentials  associated  with  control-by-exception  software 
for  the  two  feeder  sectors  represent  considerable  capacity  excess  for 
their  1-man  team  operations.  We  assume  tha  feeder  sector  workload  require- 
ments are  sufficiently  low  to  enable  a '^.-eder  R controller  to  handle  a 
feeder-and-final  sector  pair  at  low  traffic  levels. 

We  next  estimate  the  manning  requirements  for  the  flight  data 
position  needed  to  operate  the  flight  strip  printers.  Two  flight  data 
positions  are  currently  established  at  Bay  TRACON,  of  which  one  is 
routinely  manned  (regardless  of  training  activities).  Based  on  con- 
sultations with  facility  supervisory  personnel,  we  conservatively  assume 
that  manning  of  the  second  flight  data  position  under  the  ARTS  III  base 
system  could  be  delayed  at  most  until  traffic  activity  doubles,  as  shown 
in  Table  42.  However,  automated  data  handling  is  assumed  to  eliminate 
flight  strip  printers  and  the  attendant  manning,  and  thus  flight  data 
position  manning  is  set  at  zero  in  Tables  43  through  47  for  the  alterna- 
tive UG3RD  systems. 

The  total  multi-sector  day-shift  minimum  manning  requirements 
are  calculated  by  summing  the  sector  team  and  flight  data  manning  for 
each  traffic  factor.  (The  manning  estimates  do  not  include  staffing 
allowances  for  administration,  relief,  annual  and  sick  leaves,  excess 
shift  capacity,  training,  and  special  assignments.)  Under  the  ARTS  III 
Base  system,  we  estimate  that  a total  of  eight  manned  positions  cor- 
respond to  the  1975  day-shift  traffic  (1.0  traffic  factor),  as  shown 
in  Table  42.  This  1975  manning  level  defines  the  base  manning  fa-  *'or 
(1.0  in  Table  42)  and  is  used  as  the  reference  for  calculating  manning 
factors  for  each  traffic-factor  increment  under  each  alternative  ATC 
system.  That  is,  the  manning  factor  data  shown  in  Tables  42  through  47 
relate  each  projected  manning  requirement  to  that  of  the  1975  ARTS  III 
base  system. 


2.  Manning  Comparisons 

Our  manning  factor  calculations  corresponding  to  selected 
traffic  factors  are  summarized  by  ATC  system  in  Table  48  The  manning 
factor  estimates  are  made  under  the  assumption  of  a fixed  six-sector 
configuration,  and  these  estimates  represent  adjustments  to  the  six 
sector  teams  and  flight  data  positions  needed  to  handle  increases  to 
the  1975  traffic  activity. 

This  manning  estimation  procedure  as  applied  to  Bay  TRACON 
does  not  account  for  possible  resector izations  or  possible  traffic 
constraining  delays  induced  by  terminal  airspace  capacity  limitations. 
Our  consultations  with  Bay  TRACON  personnel  indicate  that  the  current 
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25 


+ DABS  Data  Link  (100%  Avionics)  0.50  0.50  0.88  0.88  1.00  1.38  1.38 


six  sector  design  concept  used  to  handle  SFO  operations  is  not  likely 
to  be  reconfigured  into  additional  sectors,  since  potential  terminal 
area  capacity  gains  are  not  expected  to  result  from  such  a reconfigura- 
tion. The  current  pairwise  arrangements  of  feeder-and-f inal  and  departure 
sectors  is  considered  the  most  efficient  sectorization  design  operationally 
feasible  for  SFO  traffic. 

Based  on  our  consultations  with  Bay  TRACON  personnel,  field 
observations,  and  operations  analyses,  we  conclude  that  whatever  critical 
delay-producing  bottleneck  situations  may  exist  are  related  currently  to 
SFO  airport  constraints  rather  than  terminal  airspace  constraints. 

In  regard  to  delay-related  implications  of  future  operations, 
the  manning  requirements  in  Table  48  are  shown  generally  to  increase  as 
traffic  approaches  twice  the  1975  level  and  to  gradually  level  off  as 
traffic  increases  beyond  the  2.0  factor  (or  thereafter,  depending  on  the 
alternative  UG3RD  system).  The  leveling-off  is  due  to  the  inability  of 
adding  controllers  to  those  sector  teams  operating  at  their  maximum 
manning  level  (i.e.,  2 men  for  DABS  data-link,  2.5  men  for  the  other 
systems).  Therefore,  certain  sectors  are  workload  saturated  and  cannot 
handle  additional  traffic.  In  fact,  some  delays  may  be  induced  earlier 
by  one  departure  sector  (DR-2)  which  reaches  maximum  manning  for  ARTS  III 
well  before  the  traffic  projection  doubles.  However,  delays  generated 
by  terminal  airspace  should  not  be  significant  since  SFO  traffic  is  pro- 
jected to  increase  only  by  65  percent  (relative  to  1975)  by  the  year  2000.* 

Since  major  workload  saturation  situations  would  occur  if 
traffic  increases  significantly  beyond  the  2.0  factor,  such  traffic  dis- 
ruptions would  cause  significant  change  to  the  operations  assumptions 
we  have  made  in  modeling  sector  capacity  and  manning.  Therefore,  as  far 
as  the  manning  factor  estimates  in  Table  48  are  concerned,  we  suggest 
that  comparisons  using  these  data  be  made  between  systems  only  for  those 
traffic  factors  at  or  below  2.0.  Comparisons  at  the  higher  traffic  levels 
would  have  no  realistic  meaning,  particularly  since  Bay  TRACON  is  not 
expected  to  operate  at  these  levels.  In  the  following  paragraph  we  do 
examine  manning  requirements  at  the  1.0  and  2.0  traffic  factors  for  the 
sake  of  comparing  the  potential  operational  impacts  of  the  alternative 
ATC  systems. 

In  Table  48,  the  ARTS  III  base  system  is  shown  to  be  capable 
of  handling  a doubling  of  1975  traffic  if  manning  is  also  doubled.  Sig- 
nificant reductions  in  these  manning  requirements  appear  under  the  automated 
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Airport  traffic  activity  forecast  provided  by  FAA(AVP) , October  1975. 
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data  handling  and  DABS  data  link  operations,  while  the  intermediate 
UG3RD  systems  show  incremental  gains  of  lower  magnitude.  Automated 
data  handling  reduces  manning  (relative  to  ARTS  III)  by  25  percent  for 
the  1.0  traffic  factor,  and  by  82  percent  for  the  2.0  traffic  factor. 
DABS  data  link  reduces  manning  (relative  to  ARTS  III)  by  50  percent  and 
100  percent,  respectively,  for  the  1.0  and  2.0  traffic  factors.  This 
shows  that  the  fully  upgraded  system  is  capable  of  handling  twice  the 
1975  traffic  with  the  current  manning  complement. 
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IX  LOS  ANGELES  TRACON  OPERATIONS 


The  Los  Angeles  TRACON,  a Group  I TCA  facility,  is  designed  pri- 
marily to  serve  aircraft  arrivals  and  departures  at  Los  Angeles  Inter- 
national Airport  (LAX).  The  facility  also  provides  separation  assurance 
for  traffic  enroute  through  the  area  and  for  instrument  traffic  using 
satellite  airports  outside  the  TCA  at  Hawthorne,  Santa  Monica,  Culver 
City,  and  Torrance.  The  coverage  area  of  L.A.  TRACON  extends  for  ap- 
proximately 20  miles  to  the  east  and  west  of  LAX  and  10  miles  to  the 
north  and  south.  It  is  bordered  by  the  Hollywood-Burbank  TRACON  on  the 
north,  the  Ontario  TRACON  on  the  east,  the  Coast  (Long  Beach)  TRACON  on 
the  south,  and  by  Los  Angeles  ARTC  Center  airspace  above  10,000  ft.  and 
to  the  west.  A separate  contingent  of  controllers  man  the  Los  Angeles 
ATCT,  although  both  the  Los  Angeles  tower  and  TRACON  controllers  are 
part  of  a single  administrative  facility,  the  Los  Angeles  Tower-TRACON. 
The  tower  and  TRACON  are  not  collocated. 


A.  Operational  Overview 

The  map  in  Figure  9 shows  the  geographic  coverage  and  sectorization 
structure  of  the  facility.  The  sector  structure  shown  conforms  to  a 
standard  "West"  wind  plan  in  which  aircraft  land  in  a westerly  direction 
on  either  of  the  Runway  25  or  Runway  24  complexes;  both  complexes  are 
closely  spaced  dual  parallel  runways.  This  sector  structure  will  shift 
to  accommodate  wind  and  weather  conditions  that  call  for  landings  in  the 
"opposite,"  easterly  direction. 

L.A,  TRACON  also  participates  in  a unique  noise  abatement  procedure 
in  which  downward  approaches  and  standard,  upward  departures  require 
aircraft  to  proceed  in  opposite  headings  during  those  night  and  early 
morning  hours  when  total  traffic  volume  at  LAX  is  extremely  light.  How- 
ever, during  the  periods  of  our  observation  and  data  collection  at  the 
facility,  the  West  plan  was  in  operation. 

Measurements  were  taken  and  observations  noted  at  all  four  of  the 
sectors  shown  in  Figure  9;  the  Downey  Arrival  (AR-1)  and  Stadium  Arrival 
(AR-2)  sectors  and  the  South  Departure  (DR-1)  and  North  Departure  (DR-2) 
sectors.  Both  the  24  and  25  runway  complexes  are  each  used  for  landings 
and  take-offs.  Generally,  the  AR-1  sector  controls  aircraft  approaching 
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FIGURE  9 WEST  PLAN  PRIMARY  ARRIVAL  AND  DEPARTURE  ROUTES  FOR 
LOS  ANGELES  TRACON 
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straight-in  from  the  east  and  landing  on  the  25  runway,  while  the  AR-2 
sector  controls  aircraft  turning  into  the  24  runway  complex.  However, 
aircraft  under  control  of  one  sector  may  use  the  airport  approaches 
normally  controlled  by  the  other  sector.  For  example,  because  of  air- 
port ground  taxi  routing  restrictions  and  terminal  design,  weight  limited 
heavy  (including  jumbo)  and  general  aviation  aircraft  must  land  in  the 
24  runway  complex,  normally  landing  on  runway  24R. 

Under  visual  approach  operations,  simultaneous  side-by-side  landings 
to  both  runways  on  each  complex  are  permitted.  Under  instrument  con- 
dition, in-trail  operations  to  both  the  24  and  25  complexes  are  performed, 
but  not  simultaneously  side-by-side  to  24R  and  24L  runways,  nor  simul- 
taneously to  25R  and  25L  runways.  In  effect,  simultaneous  side-by-side 
approaches  to  each  complex  are  allowed,  but  not  to  the  closely  spaced 
parallel  runways  within  each  complex.  During  periods  of  heavy  traffic 
under  instrument  conditions,  two  parallel  monitor  positions,  PM-1  and 
PM-2,  are  deployed  to  ensure  lateral  and  intrail  separation  of  approach- 
ing aircraft.  PM-1  monitors  aircraft  to  the  25  runway  complex,  and  PM-2 
monitors  the  24  runway  complex. 

Brief  descriptions  of  the  four  sectors  and  the  instrument  and  visual 
approach  operations  are  given  below. 


B.  Sector  Traffic  Operations 
1.  Arrival  Sectors 


a.  Downey  Arrival  Sector  (AR-1) 

The  Downey  Arrival  Sector  processes  the  typically  heavy 
traffic  arriving  at  LAX  from  the  east  and  south  and  all  instrument  opera- 
tions at  the  Hawthorne  (HHR)  Airport.  Where  parallel  approaches  are  in 
progress  at  LAX,  the  Downey  Controllers  will  usually  sequence  traffic 
to  the  Runway  25  complex.  In  general,  controller  duties  are  similar  to 
those  exercised  by  Stadium  Sector  personnel. 

Figure  10  shows  the  principal  arrival  and  crossing  routes 
used  in  the  Downey  Sector. 

These  routes  are  designated  by  number  as  follows: 

• Route  Ic  for  arrivals  at  LAX  from  the  east. 

This  is  the  primary  arrival  corridor  through 
the  Downey  Sector  and  is  used  by  high  speed 
commercial  jets. 
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• Route  Id  for  arrivals  at  lAX  fv<jin  tlie  soutli 
over  SBI.  It  too,  Is  used  mainly  by  com- 
mercial Jet  aircraft. 

• Route  2 for  instrument  traffic  arriving  at 
and  departing  HHR. 

• Route  3,  for  north-south  traffic  tlirough  tlie 
sector.  It  is  largely  altitude  separated 
from  Routes  Ic  and  Id  traffic. 


FIGURE  10  DOWNEY  ARRIVAL  (AR  1|  ROUTES 


As  Indicated  in  F’lgure  10,  most  traffic  on  Route  Ic  enters  the  sector 
at  the  LAX  localizer  heading  about  25  miles  east  of  the  airport.  Most 
Jet  traffic  on  Ic  enters  the  sector  at  or  descending  to  10,000  feet, 
crosses  the  Downey  Intersection  (about  15  miles  from  LAX)  at  or  descend- 
ing to  4,000  ft.,  and  is  handed  off  to  the  L.A,  tower  near  the  LOM  at 
about  2,000  ft.  Route  Id  Jet  traffic  enters  over  the  Seal  Beach  VORTAC 
(SLl)  at  or  descending  to  7,000  ft.  and  is  typically  vectored  to  the 
localizer  final  approach  heading,  intersecting  it  and  merging  with  the 
Route  Ic  and  Stadium  arrival  flows  at  4,000  to  6,000  feet.  The  rela- 
tively high  volumes  through  the  Downey  Sector  require  frequent  speed 
control  directives,  particularly  to  aircraft  on  Route  Ic.  Most  LAX 
arrival  jet  traffic  on  Routes  Ic  and  Id  crosses  the  Downey  Intersection 
between  230  and  270  knots,  with  aircraft  in  potential  overtaking  situa- 
tions occasionally  reduced  to  200  kts  or  less. 

Both  Routes  Ic  and  Id  contain  small  amounts  of  relatively 
low  speed  general  aviation  and  commuter  air  traffic  Inbound  to  LAX;  this 
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traffic  usually  remains  altitude  separated  from  the  higher,  faster  traf- 
fic on  these  routes  until  the  Downey  intersection  is  reached.  The  slower 
traffic  is  generally  assigned  to  the  Runway  24  complex  for  easy  access 
to  the  LAX  commuter  terminal.  It  proceeds  through  the  sector  at  speeds 
between  130  and  170  kts. 

The  potential  for  overtaking  conflicts  between  aircraft 
under  Downey  Sector  Control  is  especially  high  on  Route  Ic  inbound  to 
Downey  Intersection  and  fairly  high  for  the  Route  Id  inbounds  to  Downey, 
while  overtaking  conflicts  on  Routes  2 and  3 appear  to  be  insignificant. 
Crossing  conflicts  in  the  sector  appear  to  be  minimised  through  the 
strict,  altitude  separated  structuring  of  intersecting  air  routes  and 
arrival  corridors.  This  is  especially  true  of  the  intersection  of 
Route  3 with  the  LAX  arrivals  on  Routes  Ic  and  Id.  Merging  conflicts, 
which  occur  between  Downey  Intersection  and  the  LOM  create  special  prob- 
lems for  both  Downey  and  Stadium  arrival  controllers  since  these  con- 
flict situations  depend  on  runway  assignments,  instrument  or  visual 
approach  conditions,  and  the  traffic  volume  and  aircraft  type  mix  in 
both  sectors  at  a given  time.  Our  analysis  of  the  potential  merging  con- 
flicts for  each  type  of  approach  condition  is  described  shortly. 


b . Stadium  Arrival  Sector  (AR-2) 

The  Stadium  Arrival  Sector  handles  arrival  flights  to 
LAX  from  the  north  and  west  plus  instrument  approaches  to  the  Santa 
Monica  airport  and  miscellaneous  crossing  traffic.  Controller  responsi- 
bilities include  the  full  positive  control  of  all  instrument  approaches 
to  LAX  plus  the  sequencing  of  all  visual  approaches  so  that  the  appro- 
priate separation  standards  are  met  and  maintained.  This  involves  the 
use  of  radar  vectoring  and  speed  control  directives  for  all  traffic  and 
the  issuance  of  runway  assignment  and  traffic  identification  instructions 
to  visual  approach  traffic. 

Figure  11  shows  the  principal  arrival  and  crossing  routes 
used  in  the  stadium  sector. 

These  routes  are  designated  by  number  as  follows: 

• Route  la  for  arrivals  to  LAX  from  San  Francisco 
and  other  points  north  and  west.  This  is  the 
primary  arrival  corridor  through  the  Stadium 
sector,  and  is  used  mainly  by  commercial,  high 
performance  jet  aircraft. 
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• Route  lb  for  arrivals  to  LAX  from  the  Ventura 
area  and  points  west.  This  usually  includes 

a high  percentage  of  general  aviation  and  com- 
muter aircraft  that  is  altitude  separated  from 
the  faster  Route  la  traffic  between  Saddle  and 
SMO. 

• Route  2,  an  aggregation  of  routes  for  traffic 
using  Santa  Monica  Airport. 

• Route  3,  roughly  corresponding  to  the  V459  air- 
way, for  aircraft  arriving  at  Hawthorne  and 
other  satellite  airports,  or  crossing  the  sector 
on  north  or  south  headings.  It  is  altitude 
separated  from  most  of  the  traffic  on  the  localizer 
approach  path  to  LAX. 


A VIRGINIA 


FIGURE  11  STADIUM  ARRIVAL  (AR-2)  ROUTES 


As  indicated  in  Figure  11,  most  of  the  traffic  on  Route 
la  enters  the  sector  near  the  Virginia  Fix  at  or  descending  to  11,000  ft., 
turns  east  over  Saddle  at  9,000  to  10,000  ft.,  and  crosses  SMO  at  approx- 
imately 7,000  ft.  Aircraft  proceed  east  of  SMO  and  at  4,000  to  5,000  ft. 
are  radar  vectored  to  the  base  and  final  approaches,  reaching  the  local- 
izer outer  marker  (IX)M)  at  about  2,000  ft.,  where  they  are  handed  off 
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to  the  tower.  Under  light-to-moderate  traffic  conditions.  Route  la 
aircraft  are  allowed  to  decelerate  at  the  pilot's  discretion,  with  most 
aircraft  slowing  to  around  250  kts  at  SMO  and  200  kts  at  LOM. 

Route  lb  traffic  crosses  Saddle  at  7,000  ft.  and  the  SMO 
area  at  less  than  5,000  ft.  Most  aircraft  on  this  route  are  turned  in- 
bound on  the  base  approach  leg  at  the  LX)M,  which  effectively  removes 
much  of  the  overtaking  conflict  potential  with  the  faster  Route  la  traf- 
fic, leaving  instead  a potential  merging  conflict  point  with  Route  lb 
traffic  and  other  inbound  traffic  at  the  localizer.  Most  Route  lb  traf- 
fic uses  the  Runway  24  complex. 

Major  potential  conflicts  in  this  sector  include  a sig- 
nificant amount  of  overtaking  on  Route  la  and  the  merging  of  la  traffic 
at  the  LAX  localizer  with  inbounds  from  the  east  and  south  through  the 
Downey  arrival  sector.  (Both  the  instrument  and  visual  approach  conflict 
potentials  at  the  LAX  localizer  are  discussed  below.)  The  potential  for 
crossing  conflicts  is  quite  high  between  la  traffic  and  departures  out 
of  LAX  heading  east  through  the  North  Departure  sector,  as  will  be  dis- 
cussed shortly.  Some  crossing  conflicts  are  possible  between  aircraft 
on  Routes  2 and  3,  while  some  overtake  conflict  potential  exists  on  both 
routes. 


Aircraft  separation  minimums  are  3 to  6 miles,  depending 
on  the  pairwise  aircraft  size  and  type  mixes  involved  on  relative  air- 
craft headings. 

2.  Approach  Characteristics 

a.  Instrument  Approach  Merges 

Figure  12  below  shows  the  five  distinct  merge  points  that 
are  assumed  to  exist  at  the  LAX  localizer  during  instrument  approach 
conditions,  when  simultaneous  IFR  landings  are  performed  on  the  Runway 
24  and  25  ILS's. 

The  traffic  composition  of  each  of  the  five  merge  points, 
which  can  involve  aircraft  from  both  arrival  sectors,  is  briefly  de- 
scribed below.  They  are: 
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FIGURE  12  INSTRUMENT  APPROACH  MERGE  POINTS 


• Point  1,  which  combines  most  jet  traffic  (except 
jumbos)  on  Route  Ic  with  most  jet  traffic  on 
Route  Id  (except  jumbos)  at  Downey  Intersection 
for  landing  on  Runway  25.  (Jumbos  and  some  other 
larger  aircraft  are  usually  too  heavy  to  use  the 
Runway  25  complex.) 

• Point  1,  which  combines  some  Route  Id  heavy  jets 
and  all  Route  Id  and  Ic  jumbos  with  approximately 
half  the  jet  traffic  inbound  from  the  Northwest 
on  Route  la.  Merging  takes  place  at  or  near  the 
Downey  intersection  for  landing  on  Runway  24. 
Route  Id  traffic  is  assumed  to  cross  over  Route 
Ic  traffic  to  Runway  25. 

• Point  3,  which  combines  all  point  2 traffic  with 
the  slower  Route  Id  general  aviation  and  commuter 
traffic  for  landing  on  Runway  24.  Merging  is  as- 
sumed to  take  place  halfway  between  Downey  Inter- 
section and  IX)M.  This  Route  Id  traffic  is  as- 
sumed to  cross  beneath  Runway  25  traffic  by  1^000 
to  2,000  feet. 

• Point  4,  which  adds  about  half  the  Route  la  jet 
traffic  to  the  Runway  25  stream  at  a near  Downey 
Intercept.  The  Route  la  traffic  is  assumed  to 
cross  under  the  Runway  24  traffic.  (The  Runway 
25  complex  is  a convenient  terminal  access  for 
several  airlines  flying  into  LAX  from  the  north- 
west.) 
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• Point  5,  which  combines  Funway  24  traffic  with 
Marina  arrivals  through  the  Stadium  sector 
Route  lb.  Merging  is  assumed  to  take  place  at 
the  LOM. 

For  our  analysis  purposes,  the  overtake  conflict  workload 
is  allocated  to  each  arrival  controller  based  on  the  traffic  composition 
of  each  route  segment  in  the  merge  area.  For  example,  if  half  the  traf- 
fic on  the  Runway  25  localizer  between  Downey  Intersection  and  LOM 
entered  the  Downey  sector,  then  that  arrival  controller  is  assumed  to  re- 
tain control  of  those  aircraft  only,  and  he  is  therefore  assigned  half 
the  overtake  conflict  processing  necessary  on  that  segment.  The  remain- 
ing workload  would  be  assigned  to  the  Stadium  sector  controller. 


c.  Visual  Approach  Merges 

Figure  13  shows  the  merge  points  assumed  to  remain  in 
effect  under  visual,  side-by-side  approach  conditions.  Merge  points  2 
and  4 have  been  largely  eliminated  by  the  assignment  of  Route  la  traffic 
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FIGURE  13  VISUAL  APPROACH  MERGE  POINTS 


under  Stadium  control  to  Runways  25R  and  24R.  A small  amount  of  merging 
at  point  2 will  occasionally  be  necessary  to  combine  Route  Ic  and  Id 
jumbo  and  heavy  jet  traffic.  All  altitude  crossing  separations  for  in- 
strument approaches  are  assumed  to  hold  for  visual  approaches;  these  are 
indicated  by  the  loops  in  Figure  13.  The  remaining  merging  and  overtaking 
conflict  workloads  are  distributed  among  controllers  and  coordinators  as 
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before,  although  much  conflict  avoidance  work  will  be  replaced  by  routine 
"see  and  be  seen"  visual  approach  instructions. 


3.  Departure  Sectors 

a.  South  Departure  Sector  (DR-1) 

Figure  14  shows  the  major  departure  and  crossing  routes 
used  in  the  South  Departure  Sector. 
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FIGURE  14  SOUTH  DEPARTURE  (DR-1)  ROUTES 

These  routes  are  used  as  follows: 

• Route  Ih  for  oceanic  departures  to  the  west 
and  southwest. 

• Route  li  primarily  for  commercial  jet  traffic 
to  San  Diego  and  points  south  and  east. 

• Route  Ij  primarily  for  commercial  jet  traffic 
over  the  Seal  Beach  VORTAC  to  the  east  and 
southeast. 

• Route  2 for  general  aviation  and  coomuter 
traffic  to  Ontario,  Santa  Ana  and  points  east, 
and  Instrument  departures  from  Hawthorne. 

• Route  3,  as  a continuation  of  North  Departure 
Route  3 for  enroute  traffic  north  to  the 
Hollywood-Burbank  area. 


RTE  3 
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Aircraft  departing  LAX  on  Routes  Ih,  li  and  Ij  enter  the  sector  at  or 
climbing  to  2,000  ft.  and  are  handed  off  to  the  Los  Angeles  ARTC  Center 
at  or  climbing  to  altitudes  between  7,000  and  10,000  ft.  Aircraft  on 
Route  2 departing  LAX  climb  to  and  maintain  altitudes  under  4,000  ft. 
in  TRACON  airspace,  while  HHR  departures  often  climb  to  7,000  in  a cir- 
cling pattern,  leaving  the  TRACON  at  7,000  ft.  above  the  airport.  Route 
3 traffic  maintains  4,000  to  5,000  ft.  altitudes  through  the  sector. 

Route  1 aircraft  tend  to  climb  rapidly  through  the  sector 
and  are  therefore  above  most  other  aircraft  at  points  where  their  routes 
intersect,  thereby  minimizing  the  potential  for  crossing  conflicts. 

The  potential  for  overtaking  conflicts,  however,  is  high  on  Routes  li 
and  Ij  and  moderate  on  Routes  Ih,  2 and  3. 

b.  North  Departure  Sector  (DR-2) 

Figure  15  shows  the  major  departure  and  crossing  routes 
used  in  the  North  Departure  sector.  These  routes  are  designated  and 
used  as  follows: 


EXPECT  RADAR  VECTOR 
FOR  TURN 


Denotes  Stadium,  AR-2 

Sector  Route  la  Arrivals 


SA-4416-37 


FIGURE  15  NORTH  DEPARTURE  (DR-2)  ROUTES 


• Route  le  for  departures  to  the  east. 

• Route  If  for  departures  to  the  north  and  north- 
west. 

• Route  Ig  for  oceanic  departures. 

• Route  2 for  low  level,  general  aviation  and  com- 
muter traffic  to  Ventura,  Santa  Barbara,  and 
other  points  north  and  west. 
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• Route  3 for  traffic  enroute  through  the 
TRACON  to  the  Hollywood-Burbank  area  and 
points  north. 

• Route  4 for  instrument  departures  from 
Santa  Monica  (SMO)  and  Hughes  (OVR)  Airports. 
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X LOS  ANGELES  TRACON  ARTS  III  MODEL 


SRI  conducted  a field  experiment  at  Los  Angeles  TRACON  during  the 
week  of  May  3,  1976,  which  included  observations  of  the  operations  of 
the  two  arrival  sectors  (AR-1  and  AR-2)  and  the  two  departure  sectors 
(DR-1  and  DR-2) . Workload  modeling  data  are  based  on  data  measurements 
taken  during  one  1-hour  observation  session  for  each  of  the  four  sectors. 
During  these  observation  sessions,  AR-1  was  operating  with  a 1.5-man  team, 
AR-2  with  a 2.5-man  team,  and  the  two  departure  sectors  were  each  operat- 
ing as  2.5-man  teams;  visual  operations  were  in  effect,  and  parallel  moni- 
toring positions  (PM-1  and  PM-2)  were  not  manned.  Two  additional  1-hour 
sessions  observed  each  arrival  sector,  during  which  instrument  operations 
were  in  effect  part  of  the  time  with  the  PM-1  and  PM-2  manned.  Although 
detailed  task  activity  measurements  were  not  obtained  during  these  latter 
sessions,  these  observations  aided  our  modeling  of  instrument  operations. 

Our  Los  Angeles  TRACON  field  observation,  data  reduction,  and  work- 
load model  formulations  closely  parallel  those  we  made  for  the  Oakland 
Bay  TRACON.  In  this  section,  we  describe  the  Los  Angeles  TRACON  models, 
but  to  avoid  repetition  do  not  discuss  many  of  the  modeling  details. 

Such  details  have  already  been  explained  during  our  analysis  of  the  Bay 
TRACON.  However,  where  Los  Angeles  and  Bay  TRACON  operations  differ,  we 
do  delineate  our  modeling  approach. 


A.  Routine  Work 

1.  Composite  Team  Routine  Event  Data 

Measurements  of  routine  event  frequencies  for  each  sector  are 
summarized  in  Table  49,  and  corresponding  minimum  task  performance  times 
for  the  composite  team  are  shown  in  Table  50.  The  basic  and  supplemental 
control  events  correspond  in  general  to  those  identified  for  the  Oakland 
Bay  TRACON  (Tables  1 and  2),  but  some  differences  should  be  noted. 

For  example,  three  additional  handoff  acceptance  events — flight 
strip  preparation,  flight  strip  printer  servicing,  and  clearance  delivery-- 
were  observed  at  the  Los  Angeles  TRACON  and  are  included  as  supplemental 
events  in  Tables  49  and  50.  These  events  account  for  the  departure  con- 
trollers' requirement  to  service  the  flight  strip  printer  (one  of  which 
is  located  near  each  departure  sector  console),  and  the  arrival  controllers' 


141 


I 


COMPOSITE  TEAM 

ROUTINE  EVENT  FREQUENCY  ESTIMATES 
LOS  ANGELES  TRACON 


Control  Event  Description 


Event  Frequency  Sector 
(event/alrcraf t) 


Event 

Function 


Control 

Jurisdiction 

Transfer 


Pilot 

Request 


Basic  Event  and 

Supplemental  Event 

AR-1 

Downey 

— 

AR-2 

Stadium 

DR-1 

South 

Departure 

DR-2 

North 

Departure 

Handoff  acceptance 

0.92 

0.86 

0.94 

0.91 

Manual  acquisition-silent 

0.92 

0.86 

0 

0 

Flight  strip  preparation 

0.92 

0.86 

0 

0 

Flight  strip  printer  servicing 

0 

0 

0.94 

0.91 

Tower  departure  call  (run  down) 

0 

0 

0.94 

0.91 

Clearance  delivery  coordination 

0 

0 

0.06 

0.09 

Controller  coordination 

0.23 

0.18 

0.17 

0.06 

Handoff  initiation-silent 

0.08 

0.14 

1.00 

1.00 

Controller  coordination 

0.15 

0 

0.14 

0.18 

Traffic 

Structuring 


Initial  pilot  call-in 
TCA  clearance  request 

Initial  controller  response 
Altitude  instruction 
Data  update 

Heading/route  instruction 
Speed  instruction 
A'*oroach/runway  advisory 
Data  update 
Traffic  advisory 
ATIS  Advisory 
Alticneter  setting  advisory 
Transponder  code  assignment 
Controller  coordination 

Altitude  instruction 
Data  update 

Controller  coordination 

Heading/route  instruction 
Controller  coordination 

Speed  instruction 

Approach  clearance 
PVD  display  update 

Runway  assignment 

Controller  coordination 

Traffic  advisory 
Pilot  altitude  report 
Pilot  heading/position  report 
Pilot  speed  report 
Miscellaneous  A/G  communication 

Frequency  change 

Transponder  code  change 
Approach /runway  advisory 
Altitude/heading/speed  Instruct  lor 


Altitude  revision 

Controller  coordination 

Route/heading  revision 
Controller  coordination 

Miscellaneous  pilot  request 


General 
Intersector 
Coord  1- 
nation 


Genera  1 
System 
OpiTut  Icn 


Pointout  acceptance 
Pointout  initiation 
Control  instruction  approval 
Planning  advisory 
Aircraft  status  advisory 

Data  block  forcing/ removal 
PVD  display  adjusti.)€nt 


s 


I 


Table  50 
COMPOSITE  TEAM 

ROUTINE  TASK  MINIMUM  PERFORhLVNCE  TIME  ESTIMATES 
LOS  ANGELES  TRACON,  SYSTEM  1— ARTS  III  BASE 


Routine  Control  Event  r ijji ion 


Event 

Function 

Sasic  F.vent  and 

SuppletBental  Event 

Control 
Jurisdiction 
i'lansf  er 

! 

Handoff  acceptance 

Manual  acquisition-silent 

Flifjht  strip  preparation 

Flight  strip  printer  servicing 
Tower  departure  call  (run  down) 
Clearance  delivery 

Controller  coordination 

Handoff  initiation-silent 

Controller  coordination 

Porforr.ani.-e  1 ir.e  by  Task  (nan~sec /event ) 


Interphone  T 
Coamini-  Ccnnuni- 


rraf f ic 
Structuring 


Initial  pilot  call-in 
TCA  clearance  request 

Initial  controller  response 
Altitude  instruction 
Data  update 

Heading/route  instruction 
Speed  instruction 
Approach/runway  advisory 
Data  update 
Traffic  advisory 
AXIS  Advisory 
Altiraeter  setting  advisory 
Tra:isponder  code  assignment 
Controller  coordination 

Altitude  instruction 
Data  update 

Controller  coordination 

Heading/route  instruction 
Controller  coordination 

Speed  Instruction 

Approach  clearance 
PVD  display  update 

Runway  assignment 

Controller  coordination 

Traffic  advisory 
Pilot  altitude  report 
Pilot  heading/position  report 
Pilot  speed  report 
Miscellaneous  A/0  communication 

Frequency  change 

Transponder  code  change 
Approach/runuay  advisory 
Altitude/heading/speed  instructior 


Altitude  revision 

Controller  coordination 

Route/heading  revision 
Controller  coordination 

Miscellaneous  pilot  request 


FolntouC  acceptance 
Pointout  initiation 
Control  instruction  approval 
Planning  advisory 
Aircraft  status  advisory 


Data  block  torcing/fon-Dval 
PVD  display  adjustr.i  tit 


requirement  to  handwrite  their  own  flight  strips  (no  printed  flight 
strips  are  delivered  to  the  arrival  sectors  and  paper  scratch  pads  are 
not  used).  Also,  clearance  delivery  coordination  is  conducted  by  the 
departure  sectors  with  some  local  towers  (other  than  LAX)  regarding  cer- 
tain aircraft  that  will  enter  the  TCA  after  take-off  from  these  lesser 
airports;  in  these  cases,  a tower  is  advising  the  TRACON  controllers  of 
an  aircraft's  flight  intention.  These  flights,  as  well  as  other  "pop- 
ups,"  enter  the  TCA  without  formal  silent  handoffs  because  other  ARTS  III 
or  NAS  Stage  A equipped  facilities  are  not  involved,  and  they  require  a 
TCA  clearance  request  A/G  communication  from  the  pilot  (which  is  treated 
as  a supplemental  event  to  the  basic  pilot  call-in,  as  in  the  Bay  TRACON 
analysis) . 


Some  minor  differences  occur  between  Bay  TRACON  and  Los  Angeles 
TRACON  traffic  structuring  events.  The  AR-2  controllers  were  usually  ob- 
served to  perform  the  data  update  event  by  marking  their  flight  strips 
(rather  than  using  keyboard  data  entry /display  operations)  to  record  the 
issuance  of  approach/runway  advisories  during  the  initial  controller  re- 
sponse to  a pilot  call-in.  The  AR-1  controllers,  however,  were  observed 
to  record  the  issuance  of  an  approach  clearance  by  using  data  entry/ 
display  operations  (a  PVD  display  update  event).  Both  Los  Angeles  TRACON 
arrival  sectors  conduct  some  routine  interphone  coordination  with  tower 
controllers  regarding  specific  runway  assignments  (the  LAX  approaches  are 
more  complex  than  those  of  SFO).  These  arrival  sectors  in  some  cases 
issue  approach/runway  advisories  to  pilots,  supplementing  a basic  fre- 
ouency  change  event  (this  repeating  of  the  approach  clearance  is  analogous 
to  instructions  given  by  both  feeder  and  final  sectors  at  Bay  TRACON). 


2.  R Controller  Routine  Event  Data 


We  allocate  the  composite  team  task  requirements  to  the  R con- 
troller for  each  of  the  four  manning  regimes  in  accordance  with  the 
allocation  rules  defined  for  the  Bay  TRACON  analysis:  the  coordinator 
performs  routine  interphone  tasks  and,  for  the  1.5-man  team,  performs 
half  the  handoff  events;  the  H controller  performs  keyboard  data  entry/ 
display  tasks  where  appropriate  (including  departure  sector  flight  strip 
printer  servicing) , and  interphone  communications  if  the  coordinator 
position  is  not  manned;  and  face-to-face  communications  apply  only  to 
the  multi-man  team  regimes.  The  resulting  R controller  task  allocations 
are  shown  in  Tables  51,  52,  53,  and  54  for  the  1-man,  1.5-man,  2-man, 
and  2.5-man  teams  respectively.  The  corresponding  R controller  routine 
event  minimum  performance  times  are  summarized  in  Table  55. 
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Table  51 
R CONTROLLER 

ROUTINE  TASK  MINIMUM  PERFORMANCE  TIME  ESTIMATES 
LOS  ANGELES  TRACON,  SYSTEM  1.  1-MAN  TEAM 


Perfornance  Time  by  Task  (nan-sec /event ) 


Traffic 

Structuring 


A/G 

Communi 

cation 


Pilot 

Request 


General 
Intersector 
Coord 1- 
natlon 


General 
System 
Oi’crac  ion 


Handoff  acceptance 

Manual  acquisition-silent 
Flight  scrip  preparation 
Flight  strip  printer  servicing 
Tover  departure  call  (run  down) 
Clearance  delivery 
Controller  coordination 

Handoff  initiation-silent 
Controller  coordination 


Initial  pilot  call-in 
TCA  clearance  request 

Initial  controller  response 
Altitude  instruction 
Data  update 

Heading/rouce  instruction 
Speed  instruction 
Approach/runway  advisory 
Data  update 
Traffic  advisory 
AXIS  Advisory 
Altimeter  setting  advisory 
Transponder  code  assignment 
Controller  coordination 

Altitude  instruction 
Data  update 

Controller  coordination 

Heading/route  instruction 
Controller  coordination 

Speed  Instmction 

Approach  clearance 
PVD  display  update 

Runway  assignment 

Controller  coordination 

Traffic  advisory 
Pilot  altitude  report 
Pilot  heading/position  report 
Pilot  speed  report 
Miscellaneous  A/G  communication 

Frequency  change 

Transponder  code  change 
Approach/runway  advisory 
Altitude/heading/speed  Instruct ior 


Altitude  revision 

Controller  coordination 

Route/heading  revision 
Controller  coordination 

Miscellaneous  pilot  request 


Pointout  acceptance 
Pointout  initiation 
Control  instruction  approval 
Planning  advisory 
Aircraft  status  advisory 


Data  block  f orclng/renoval 
PVD  display  adjustment 


Table  52 
R CONTROLLER 

ROUTINE  TASK  MINIMUM  PERFORMANCE  TIME  ESTIMATES 
U)S  ANCELES  TRACON,  SYSTFil  1,  1.5-MAN  TEAM 


Houtiiw- 

(;ontrol  Event  Her,.- 1 ipi  ion 

Perforrance  “ine  by  Task  (:ian-sec /event ) 

Event 

Function 

nasLC  Event  and 

Supplement  al  Event 

A/c 

Communi- 
cat  ion 

u.ita 
Entry/ 
Display 
3i)erat  ion 

Process- 

ing 

1 nier- 
plione 
CtiTuTlUnl- 
tat ion 

Face-to- 

Facc 

Conmuni- 
car.  ion 

Totjl 

C<*£tt  roL 

Haadotf  ticcepranre 

0 

Jur Isd ict ion 

Manual  acqui si t ion-si  1 eat 

2 

2 

I ran  ,fer 

Flight  stri])  preparation 

6 

6 

Might  strip  printer  servicing 

15 

15 

Tower  departure  call  (run  down) 

0 

Clearance  delivery 

2 

10 

12 

Controller  coordination 

3 

3 

Handoff  Initiation-silent 

3 

3 

Coni ro] ler  coordination 

3 

3 

Tiai 1 ic 

Initial  pilot  call-in 

1 1 

5 

Structuring 

TCA  clearance  request 

10 

6 

20 

Initial  controller  response 

2 

2 

Altltiaie  instruction 

3 

3 

Uata  update 

2 

2 

Heading/route  insfrviction 

3 

3 

Speed  Instruction 

3 

3 

Approach/runway  atJvi  sory 

3 

3 

Data  update 

2 

2 

Traffic  advisory 

3 

3 

ATIS  Advisory 

3 

3 

Altimeter  setting  advisory 

3 

Transponder  code  assignment 

3 

3 

2 

H 

Controller  coordination 

3 

3 

Altitude?  Instruction 

5 

5 

Data  update 

2 

2 

Controller  coordination 

3 

3 

Heading/route  instruction 

5 

5 

Controller  coordination 

3 

3 

Speed  Instruction 

5 

5 

Approach  clearance 

6 

6 

PVD  display  update 

3 

3 

Runway  assignment 

5 

5 

Controller  coordlnat i'-n 

3 

3 

Traffic  advisory 

5 

5 

Pilot  altitude  report 

5 

5 

Pilot  heading/position  report 

5 

5 

Pilot  speed  report 

5 

5 

Miscellaneous  A/C  communication 

5 

5 

Frequency  change 

4 

1 

5 

Transponder  code  change 

2 

2 

Approach/runway  advisory 

3 

3 

A1 1 Itude /heading /speed  instruction 

3 

3 

Pilot 

Altitude  revision 

6 

2 

8 

Re«{uest 

Controller  coordination 

3 

3 

Route/heading  revision 

R 

2 

10 

Controller  coordination 

3 

3 

Miscellaneous  pilot  request 

6 

6 

General 

Pointout  acceptance 

3 

3 

6 

Intersector 
Coord  1- 

Pointout  initiation 

3 

3 

nar ion 

Control  Instruction  approval 

3 

3 

Planning  .ndvlsory 

3 

3 

Aircraft  status  advisory 

0 

D.it.1  block  forcing/reroval 
?Vr>  fJlspl.Ty  .jtl  Jusni-eiit 


I 3 
( 

! 3 


General 
System 
Oporat ion 
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3 

3 


Table  53 
R CONTROLLER 

ROUTINE  TASK  MINIMUM  PERFORMANCE  TIME  ESTIMATES 
LOS  ANGELES  TRACON,  SYSTEM  1.  2-MAN  TEAM 


Routine 

Control  Event  D--scription 

. Performance  Time  by  Task  (nan-sec /event ) 

Event 

Function 

Basic  Event  and 

Supplemental  Event 

A/C 

Communi- 

cation 

Data 

Entry/ 

^Isplav 

Operatibr 

Flight 

Strip 

Process- 

inn 

Inter- 
phone 
Connuni- 
cat ion 

Facc-to~ 

Face 

Communi- 
cat ion 

Total 

Jontrol 

Hanioff  acceptance 

0 

lv:risdictioa 

^!anual  acquisition-silent 

0 

fransCer 

Flight  strip  preparation 

0 

flight  strip  printer  servicing 

0 

Tover  departure  call  (run  dou-n) 

0 

Clearance  delivery 

3 

3 

Controller  coordination 

3 

Kandoff  initiation-silent 

0 

Controller  coordination 

3 

3 

Traffic 

Initial  pilot  call-in 

4 

1 

5 

jtructuring 

TCA  clearance  request 

4 

6 

10 

Initial  controller  response 

2 

2 

Altitude  instruction 

3 

3 

Data  update 

2 

2 

Heading/route  instruction 

3 

3 

Speed  instruction 

3 

3 

Approach/runway  advisory 

3 

3 

Data  update 

2 

2 

Traffic  advisory 

3 

3 

ATIS  Advisory 

3 

3 

Altimeter  setting  advisory 

3 

3 

Transponder  code  assignment 

3 

2 

5 

Controller  coordination 

3 

3 

Altitude  instruction 

5 

5 

Data  update 

2 

2 

Controller  coordination 

3 

3 

Heading/route  instruction 

5 

5 

Controller  coordination 

3 

3 

Speed  instruction 

5 

5 

Approach  clearance 

6 

6 

PVD  display  update 

3 

3 

Runway  assignment 

5 

5 

Controller  coordination 

3 

3 

Traffic  advisory 

5 

5 

Pilot  altitude  report 

5 

5 

Pilot  heading/position  report 

5 

5 

Pilot  speed  report 

5 

5 

Miscellaneous  A/G  communication 

5 

5 

Frequency  change 

4 

1 

5 

Transponder  code  change 

2 

2 

Approach/runway  advisory 

3 

- 

Altitude/heading/speed  instruction 

3 

Pilot 

Altitude  revision 

6 

2 

8 

i Request 

Controller  coordination 

3 

3 

Route/heading  revision 

8 

2 

10 

Controller  coordination 

3 

3 

Miscellaneous  pilot  request 

6 

6 

1 General 

Pointout  acceptance 

3 

3 

Intersector 

Coordi- 

Pointout  initiation 

3 

3 

nation 

Control  instruction  approval 

3 

3 

Planning  advisory 

3 

3 

Aircraft  status  advisory 

0 

General 

Data  block  forcing/removal 

3 

< 3 

System 

I ion 

?Vn  <Jispl.iy  ad justmerit 

3 

i 3 
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Table  54 
R CONTROLLER 

ROUTINE  TASK  MINIMUM  PERFORMANCE  TIME  ESTIMATES 
LOS  ANGELES  TRACON,  SYSTEM  1,  2.5-MAN  TEAM 


Routine  Control  Event  Description 


Perfornance  Tif^e  by  Task  (ran-sec /event ) 


Event 

Basic  Event  and 

Function 

Supplemental  Event 

Iraffic  Initial  pilot  call-in 

Structuring  TCA  clearance  request 

Initial  controller  response 
Altitude  instruction 
Data  update 

Heading/ route  instruction 
Speed  instruction 
Approach/runway  advisory 
Data  update 
Traffic  advisory 
ATIS  Advisory 
Altimeter  setting  advisory 
Transponder  code  assignment 
Controller  coordination 

Altitude  instruction 
Data  update 

Controller  coordination 

Heading/route  instruction 
Controller  coordination 

Speed  instruction 

Approach  clearance 
PVD  display  update 

Runway  assignment 

Controller  coordination 

Traffic  advisory 
Pilot  altitude  report 
Pilot  heading/position  report 
Pilot  speed  report 
Miscellaneous  A/G  communication 

Frequency  change 

Transponder  code  change 
Approach/runway  advisory 
Altitude/heading/ speed  instruct ior 


Pilot  Altitude  revision 

Request  Controller  coordination 

Route/heading  revision 
Controller  coordination 

Miscellaneous  pilot  request 


General 

Intersector 

Coordi- 

nation 

Pointout  acceptance 

Pointout  initiation 

Control  instruction  approval 

Planning  advisory 

Aircraft  status  advisory 

General 
System 
Operat ion 

Data  block  forcing/reroval 

PVD  display  ad justmcr.t 
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Table  55 
R CONTROLLER 

ROUTINE  EVENT  MINIMUM  PERFORMANCE  TIME  ESTIMATES 
LOS  ANGELES  TRACON,  SYST^l  1— ARTS  III  BASE 


Roi:tine  Control  Event  Description 


Event  Basic  Event  and 
Function  Supplemental  Event 


Handoff  acceptance 

Manual  acejuisit ion-silent 
Flight  strip  preparation 
Flight  strip  printer  servicing 
Tower  departure  call  (run  down) 
Clearance  delivery  coordination 
Controller  coordination 

Handoff  initiation-silent 
Controller  coordination 


iraffic  Initial  pilot  call-in 

Structuring  TCA  clearance  request 

Initial  controller  response 
Altitude  Instruction 
Data  update 

Heading/route  Instruction 
Speed  instruction 
Approach /runway  advisory 
Data  update 
Traffic  advisory 
ATIS  Advisory 
Altimeter  setting  advisory 
Transponder  code  assignment 
Controller  coordination 

Altitude  instruction 
Data  update 

Controller  coordination 

Heading/route  instruction 
Controller  coordination 

Speed  Instruction 

Approach  clearance 
PVD  display  update 

Runway  assignment 

Controller  coordination 

Traffic  advisory 
Pilot  altitude  report 
Pilot  heading/position  report 
Pilot  speed  report 
Miscellaneous  A/G  communication 

Frequency  change 

Transponder  code  change 
Approach/runway  advisory 
Altitude /heading/ speed  instruct lor 


Pilot  Altitude  revision 

Request  Controller  coordination 

Route/heading  revision 
Controller  coordination 

Miscellaneous  pilot  request 


Performance  Time  by  Team  (nan-sec/evcni ) 


1 . 0-Man 
Team 


1.5-Man 

Tuan 


6 

6 

15 

15 

General 
Intcrsector 
Coord  1- 
natlon 

Po intout  acceptance 

Polntout  initiation 

Control  instruction  approval 

Planning  advisory 

Aircraft  status  advisory 

General 
S>stem 
r);>rrnt  ion 

Data  block  forclng/romoval 

rVD  lUsplay  adjusti.ent 

Indicated  event  occurs  at  half  the  frequency  rate  shown  in  Table  49. 
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Routine  Workload  Weightings 

The  R controller  routine  workload  weighting  is  calculated  by 
multiplying  event  frequencies  (Table  49)  by  corresponding  event  per- 
formance times  (Table  55)  and  summing  the  products.  The  resulting  work- 
load weightings  are  listed  in  Table  56  for  the  four  sector  manning  regimes 
at  each  of  the  four  sectors. 


B . Surveillance  Work 

Surveillance  workload  weightings  based  on  the  assumption  of  1.25 
man-sec/aircraf t-min  for  PVD  scanning  is  shown  in  Table  57  for  the  four 
sectors.  The  transit  times  in  Table  57  are  those  reported^^  for  each 
sector  by  Los  Angeles  TRACON.  The  transit  times  shown  for  the  arrival 
sectors  do  not  include  that  portion  of  time  aircraft  spend  on  the  final 
approach  during  which  separation  is  maintained  by  parallel  monitors  under 
instrument  operations  or  by  pilots  under  visual  operations;  this  time 
would  increase  by  2.5  min  the  sector  transit  times  shown  in  Table  57  for 
both  arrival  sectors. 


Table  56 


R CONTROLLER  ROUTINE  WORKLOAD  WEIGHTINGS 
LOS  ANGELES  TRACON,  SYSTEM  1— ARTS  III  BASE 


Sector 

R Controller  Routine  Workload  Weighting, 
k^ , by  Team  (man-sec/aircraft) 

1-Man 

Team 

1 . 5-Man 
Team 

2 -Man 
Team 

2 . 5-Man 
Team 

AR-1,  Downey  Arrival 

77 

72 

63 

57 

AR-2,  Stadium  Arrival 

102 

97 

87 

86 

DR-1,  South  Departure 

69 

63 

45 

42 

1 

DR-2,  North  Departure 

71 

65 

46 

44 
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Table  57 


R CONTROLLER  SURVEILLANCE  WORKLOAD  WEICIITINC 
LOS  ANGELES  TRACON,  SYSTEM  ]— ARTS  III  RASE 


Sector 

Aircraft  Average  Tran- 
sit Time,  t (min) 
s 

Surveillance  Workload 
Weighting,  ct 

(man-sec/a Ircraf  t ) 

AR-1,  Downey  Arrival 

7.5 

9.18 

AR-2,  Stadium  Arrival 

7.  5 

9.  38 

DR-1,  South  Departure 

5 

6.25 

DR-2,  North  Departure 

5 

6.25 

Surveillance  workload  constant,  c = 1.25  man-sec/ai rcraf t-min . 


C.  Conflict  Work 


1 . Conflict  Event  Data 


Application  of  the  potential  conflict  modeling  relationships 
(Appendix  A)  to  the  traffic  operation  and  route  pattern  characteristics 
for  each  of  the  four  Los  Angeles  TRACON  sectors  provides  the  conflict 
event  frequencies  shown  in  Table  58.  Distinction  is  made  between  visual 
and  instrument  approach  operations  to  account  for  coordinated  approach 
mergings  and  increased  overtaking  work  during  instrument  conditions. 

In  accordance  with  the  operational  descriptions  given  for  the 
two  arrival  sectors,  coordinated  approach  mergings  are  made  at  fewer 
merge  points  during  visual  rather  than  instrument  approach  operations, 
causing  the  frequency  of  such  events  to  be  less  during  visual  than  during 
instrument  conditions.  The  overtaking  conflict  frequencies  calculated 
in  Table  58  for  the  two  arrival  sectors  during  Instrument  approach  opera- 
tions are  double  twice  calculated  for  visual  operations,  because  increased 
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DR-2,  North  Departure 


in-trail  spacings  are  assumed  necessary  during  instrument  operations  for 
coordinated  approach  mergings  of  both  sectors'  traffic. 

Spot  checks  of  conflict  task  minimum  performance  times  observed 
at  Los  Angeles  TRACON  showed  them  to  be  consistent  with  those  of  Bay 
TRACON.  For  our  modeling  purposes,  we  use  the  R controller  conflict  event 
times  previously  defined  for  Bay  TRACON.  These  minimum  performance  times 
^^c>  *-m»  ^o’  and  tg,  respectively)  for  crossing,  local  merging,  overtaking, 
and  coordinated  approach  merging  situations  measured  in  man-sec/conflict 
are : 


t 

c 

= 

40, 

for 

1-man, 

1. 5-man, 

2 -man. 

and 

2. 

5 -man 

teams ; 

t 

m 

= 

35, 

for 

1 -man. 

1 5-man, 

2-man, 

and 

2. 

5 -man 

teams ; 

t 

o 

= 

30, 

for 

1-man, 

1 . 5-man, 

2 -man. 

and 

2. 

5 -man 

teams ; 

t 

a 

= 

32. 

5,  for  1-man 

and  2-man  teams 

= 

20. 

5,  for  1.5-man  and  2. 

5-man 

teams 

Recall  that  the  R controller  time  for  coordinated  approach 
merging  (tg)  varies  by  team  manning  regime  because  the  coordinator  decides 
aircraft  sequences  and  calls  them  out  to  each  R controller. 


2,  Conflict  Workload  Weighting 

Conflict  workload  weightings  are  estimated  by  multiplying  the 
conflict  event  frequencies  (Table  58)  by  the  corresponding  performance 
time  (Table  11).  Results  of  these  calculations  are  presented  in  Table  59 
for  visual  and  instrument  approach  conditions  for  the  four  sectors. 
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XI  LOS  ANGELES  TRACON  UG3RD  SYSTEM  MODELS 


In  this  section  we  describe  the  operational  impacts  of  the  UG3RD 
automation  features  using  our  models  of  R controller  workload  for  the 
four  Los  Angeles  TRACON  sectors.  These  features,  including  their  as- 
sumed technological  and  operational  characteristics,  are  the  same  as 
those  addressed  in  our  Bay  TRACON  analysis: 

• Automated  data  handling  (ADH) 

• Basic  metering  and  spacing  (M&S) 

• Area  navigation  (RNAV) 

• Discrete  address  beacon  system  (DABS)  data  link 

• DABS-based  intermittent  positive  control  (IPC) . 

The  basic  modeling  assumptions  used  to  analyze  the  UG3RD  systems 
are  the  same  as  for  our  Bay  TRACON  study.  Thus,  we  present  here  only 
the  workload  modeling  data  pertinent  to  the  Los  Angeles  TRACON  sectors. 


A.  Automated  Data  Handling  (System  2) 

The  primary  element  of  automated  data  handling  is  the  electronic 
tabular  display  system  which  eliminates  paper  flight  strip  processing 
and  consolidates  on-line  data  presentation  and  maintenance  into  a com- 
puter interactive  format. 


1.  ADH  Workload  Model 


The  tabular  display  will  alter  many  of  the  sector  team's  data 
maintenance  activities  that  we  have  included  as  part  of  our  routine 
workload  model.  We  foresee  no  impact  on  our  surveillance  or  conflict 
work  models. 

Our  interpretations  of  effects  of  the  tabular  display  on  the 
composite  team's  routine  task  performance  times  are  summarized  in 
Table  60.  The  corresponding  R controller  routine  task  performance  times 
for  the  four  team  manning  regimes  are  shown  in  Tables  61,  62,  63,  and  64. 
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Table  60 
COMPOSITE  TEAM 

ROUTINE  TASK  MINIMUM  PERFORMANCE  TIME  ESTIMATES 
LOS  ANGELES  TRACON,  SYSTEM  2— AUTOMATED  DATA  HANDLING 


Routine  Control  Event  Description 


Performance  Time  by  Task  (man-scc/event) 


raffle 

trucCuring 


: General 
^ Intersector 
1 Coordi- 
nation 


General 

Systeo 

Operation 


Initial  pilot  call-in 
TCA  clearance  request 

Initial  controller  response 
Altitude  instruction 
Data  update 

Heading/route  instruction 
Speed  instraction 
Approach/runway  advisory 
Data  update 
Traffic  advisory 
ATIS  Advisory 
Altiiaeter  setting  advisory 
Transponder  code  assignment 
Controller  coordination 

Altitude  instruction 
Data  update 

Controller  coordination 

Heading/route  instruction 
Controller  coordination 

Speed  Instruction 

Approach  clearance 
PVD  display  update 

Runway  assignment 

Controller  coordination 

Traffic  advisory 
Pilot  altitude  report 
Pilot  heading/position  report 
Pilot  speed  report 
Miscellaneous  A/G  communication 

Frequency  change 

Transponder  code  change 
Approach/runway  advisory 
Altitude/heading/speed  instructior 


Altitude  revision 

Controller  coordination 

RouCe/headlng  revision 
Controller  coordination 

Miscellaneous  pilot  request 


Pointout  acceptance 
Pointout  initiation 
Control  instruction  approval 
Planning  advisory 
Aircraft  status  advisory 


Data  block  forcing/removal 
PVD  display  adjustvient 


System  1 performance  tines  are  Indicated  by  parentheses. 
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Table  6^ 

R CONTROLLER 

ROUTINE  TASK  MINIMUM  PERFORMANCE  TIME  ESTIMATES 
LOS  ANGELES  TRACON.  SYSTEM  2,  1-MAN  TEAM 


Routine  Control  Event  Description 


Perfornance  Time  by  Task  (nan-sec /event ) 


5 


Table  63 
R CONTROLLER 

ROUTINE  TASK  MINIMUM  PERFORMANCE  TIME  ESTIMATES 
LOS  ANGELES  TRACON.  SYSTEM  2,  2-MAN  TEAM 


Routine  Control  Event  Description 


Pcrfornance  Time  by  Task  (man-sec/event) 


Event  Basic  Event  and 
Function  Supplemental  Event 


Kaudoff  acceptance 

Manual  acquisition-silent 
Flight  strip  preparation 
Flight  strip  printer  servicing 
Tower  departure  call  (run  downi) 
Clearance  delivery 
Controller  coordination 

Handof f initiation-silent 
Controller  coordination 


raffic  Initial  pilot  call-in 

tructuring  TCA  clearance  request 

Initial  controller  response 
Altitude  instruction 
Data  update 

Heading/ route  instruction 
Speed  instruction 
Approach/runway  advisory 
Data  update 
Traffic  advisory 
ATIS  Advisory 
Altimeter  setting  advisory 
Transponder  code  assignment 
Controller  coordination 

Altitude  instruction 
Data  update 

Controller  coordination 

Heading/route  instruction 
Controller  coordination 

Speed  instruction 

Approach  clearance 
FVD  display  update 

Runway  assignment 

Controller  coordinati''n 

Traffic  advisory 
Pilot  altitude  report 
Pilot  heading/position  report 
Pilot  speed  report 
Miscellaneous  A/G  communication 

Frequency  change 
Transponder  code  change 
Approach/runway  advisory 
Altltude/headlng/speed  in struct lot 


A/G 

Communi 
car  ton 


Pilot 

Request 

Altitude  revision 

Controller  coordination 

Route/heading  revision 

Controller  coordination 

Miscellaneous  pilot  request 

General 
Intersector 
Coord i- 
nation 

Pointout  acceptance 

Pointout  initiation 

Control  instruction  approval 

Planning  advisory 

Aircraft  status  advisory 

General 
System 
Oporat ion 

Data  block  forclng/renoval 

rVD  display  adjustment 

Table  64 
R CONTROLLER 

ROUTINE  TASK  MINIMUM  PERFORMANCE  TIME  ESTIMATES 
LOS  ANGELES  TRACON,  SYSTEM  2,  2.S-MAN  TEAM 


Routine  Control  Event  Description 


Performance  Time  by  Task  (man-sec /event ) 


Basic  Event  and 
Supplemental  Event 


Handof f acceptance 

Manual  acquisition-silent 
Flight  strip  preparation 
Flight  strip  printer  servicing 
Tower  departure  call  (run  down) 
Clearance  delivery 
Controller  coordination 

Handof f initiation-silent 
Controller  coordination 


Initial  pilot  call-in 
TCA  clearance  request 

Initial  controller  response 
Altitude  instruction 
Data  update 

Heading/route  instruction 
Speed  instruction 
Approach/runway  advisory 
Data  update 
Traffic  advisory 
ATIS  Advisory 
Altimeter  setting  advisory 
Transponder  code  assignment 
Controller  coordination 

Altitude  instruction 
Data  update 

Controller  coordination 

Heading/route  instruction 
Controller  coordination 

Speed  i iStruction 

Approach  clearance 
PVD  display  update 

Runway  assignment 

Controller  coordination 

Traffic  advisory 
Pilot  altitude  report 
Pilot  heading/position  report 
Pilot  speed  report 
Miscellaneous  A/G  communication 

Frequency  change 

Transponder  code  change 
Approach/runway  advisory 
Altitude/heading/speed  instruct lor 


Altitude  revision 

Controller  coordination 

Route/heading  revision 
Controller  coordination 

Miscellaneous  pilot  request 


A/G 

Communi 
cat  ion 


General 

Intersector 

Coordi- 

nation 

Fointout  acceptance 

Point out  initiation 

Control  instruction  approval 

Planning  advisory 

Aircraft  status  advisory 

Ccne ral 
System 
Oporat ion 

Data  block  forclng/rertoval 

?VD  display  adjustment 

^Operational  cognizance 
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The  resulting  R controller  routine  event  performance  times  for  each 
regime  are  summarized  in  Table  65. 


2.  ADH  Workload  Weightings 

The  R controller  routine  workload  weightings  are  obtained  by 
multiplying  the  Table  A9  event  frequencies  by  the  corresponding  event 
performance  times  in  Table  65.  The  resulting  routine  workload  weight- 
ings for  each  sector  under  four  sector  team  manning  regimes  are  shown 
in  Table  66. 

The  R controller  surveillance  workload  weighting  (Table  57) 
and  conflict  workload  weighting  (Table  59)  calculated  for  the  ARTS  III 
base  system  also  apply  to  the  automated  data  handling  system. 


B.  Basic  Metering  and  Spacing  (System  3) 

Basic  metering  and  spacing  performs  part  of  the  decision  making 
required  to  merge  aircraft  from  divergent  directions  into  one  or  more 
final  approach  sequences. 


1.  M&S  Workload  Model 


The  M&S  feature  will  alter  the  decision  making  task  times 
that  we  have  incorporated  into  our  conflict  work  model.  We  expect  no 
impact  on  routine  or  surveillance  work  requirements. 

Our  Bay  TRACON  estimates  of  conflict  task  performance  times 
assume  that  metering  and  spacing  will  automate  that  part  of  the  merging 
and  overtaking  detection  and  assessment  tasks  devoted  to  situation  and 
sequence  identification.  Thus,  under  this  system,  the  R controller's 
potential  conflict  event  performance  times  (t^,  tjj,,  tQ,  and  t^,  respec- 
tively) for  crossing,  local  merging,  overtaking,  and  coordinated  ap- 
proach merging  situations  measured  in  man-sec/event  are: 


t = 

c 

40, 

for 

1-man, 

1,5-man, 

2 -man. 

and 

2 . 5-man 

teams ; 

t 

m 

25, 

for 

1-man, 

1.5 -man. 

2 -man. 

and 

2. 5 -man 

teams ; 

t 

n 

20, 

for 

1-man, 

1.5-man, 

2 -man. 

and 

2. 5 -man 

teams ; 

t = 22.5,  for  1-man  and  2-man  teams 

a 

= 20.5,  for  1.5-man  and  2.5-man  teams. 
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Table  65 
R CONTROLLER 

ROUTINE  EVENT  MINIMUM  PERFORMANCE  TIME  ESTIMATES 
LOS  ANGELES  TRACON,  SYSTEM  2— AUTOMATED  DATA  HANDLING 


Routine  Control  Event  Description 


Basic  Event  and 

Supplemental  Event 


Handof f acceptance 

Manual  acquisition-silent 
Fliglit  strip  preparation 
Flight  strip  printer  servicing 
Tower  departure  call  (run  down) 
Clearance  delivery  coordination 
Controller  coordination 

Handoff  initiation-silent 
Controller  coordination 


Initial  pilot  call-in 
TCA  clearance  request 

Initial  controller  response 
Altitude  instruction 
Data  update 

Heading/ route  instruction 
Speed  instruction 
Approach/runway  advisory 
Data  update 
Traffic  advisory 
ATIS  Advisory 
Altimeter  setting  advisory 
Transponder  code  assignment 
Controller  coordination 

Altitude  instruction 
Data  update 

Controller  coordination 

Headiog/route  instruction 
Controller  coordination 

Speed  instruction 

Approach  clearance 
PVD  display  update 

Runway  assignment 

Controller  coordination 

Traffic  advisory 
Pilot  altitude  report 
Pilot  heading/position  report 
Pilot  speed  report 
Miscellaneous  A/G  communication 

Frequency  change 

Transponder  code  change 
Approach/runway  advisory 
Altitude/heading/speed  instructior 


Altitude  revision 

Controller  coordination 

Route/heading  revision 
Controller  coordination 

Miscellaneous  pilot  request 


Polntout  acceptance 
Pointout  initiation 
Control  Instruction  approval 
Planning  advisory 
Aircraft  status  advisory 


Data  block  forcing/renoval 
PVD  display  adjustment 


Performance  Time  by  Team  (man-sec/evenc ) 


1 . 0-Man 
Team 

1 . 5-Man 
Team 

0 , 

r 

0 

2.5-Man 

Team 


General 

Intersector 

Coordi- 

nation 


I System 
I Oporat Ion 


0 

0 

0 

0 

0 

' 0 

0 

0 

0 

1 0 

Indicated  event  occurs  at  half  the  frequency  rate  shown  in  Table  49. 
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Table  66 


R CONTROLLER  ROUTINE  WORKLOAD  WEIGHTINGS 
LOS  ANGELES  TRACON,  SYSTEM  2— AUTOMATED  DATA  HANDLING 


Sector 

R Controller  Routine  Workload  Weighting, 
k, , by  Team  (man-sec/aircraft) 

BBI 

1.5-Man 

Team 

2 -Man 
Team 

2.5-Man 

Team 

AR-1,  Downey  Arrival 

69 

65 

60 

54 

AR-2,  Stadium  Arrival 

96 

91 

84 

80 

DR-1,  South  Departure 

49 

46 

43 

41 

DR-2,  North  Departure 

51 

48 

45 

43 

2 . M&S  Workload  Wei';htlngs 

Basic  metering  and  spacing  system  does  not  alter  frequency  of 
conflict  events^  and  the  conflict  event  frequencies  in  Table  58  calcu- 
lated for  the  current  ARTS  III  Base  System  apply.  We  multiply  the  con- 
flict event  performance  (see  above)  by  the  corresponding  Table  58  event 
frequencies  to  obtain  the  R controller  conflict  workload  weighting 
shown  in  Table  67  for  basic  metering  and  spacing. 

The  R controller  routine  workload  weighting  (Table  66)  and 
surveillance  workload  weighting  (Table  57)  corresponding  to  the  prede- 
cessor system  also  apply  to  the  basic  metering  and  spacing  system. 


C.  Conflict  Probe  (System  4) 

A sector  conflict  probe  projects  aircraft  flight  trajectories  by 
computer  calculations  and  warns  controllers  of  potential  conflict  situa- 

t Ions . 
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R CONTROLLER  CONFLICT  WORKLOAD  WEIGHTING 
LOS  ANGELES  TRACON,  SYSTEM  3— BASIC  METERING  AND  SPACING 
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1. 


Conflict  Probe  Workload  Model 


The  sector  conflict  probe  will  alter  the  sector  team's  task 
performance  time  requirements  which  are  included  in  the  conflict  work 
model.  We  foresee  no  impact  on  our  routine  work  or  PVD  surveillance 
work  models. 

The  conflict  probe  is  assumed  to  automate  detection  and  assess- 
ment tasks  in  the  manner  described  in  the  Bay  TRACON  analysis.  There- 
fore, using  a conflict  probe,  the  R controller's  potential  conflict 
event  performance  times  (t^,,  t^^,  t^,  t^,  respectively)  for  crossing, 
local  merging,  overtaking,  and  approach  merging  situations  measured  in 
man-sec/conflict  are: 


t = 

c 

25, 

for 

1-man, 

1.5-man, 

2 -man. 

and 

2. 5 -man 

teams ; 

t 

m 

20, 

for 

1-man, 

1.5-man, 

2 -man. 

and 

2. 5 -man 

teams ; 

t 

n 

15, 

for 

1-man, 

1.5-man, 

2-man, 

and 

2.5-man 

teams ; 

t = 17.5,  for  1-man  and  2-man  teams 

a 

= 15.5,  for  1.5-man  and  2.5-man  teams. 


2.  Conflict  Probe  Workload  Weightings 

No  revisions  to  the  rate  of  occurrence  of  conflict  events  are 
associated  with  the  conflict  probe,  and  the  conflict  event  frequencies 
in  Table  58  for  the  predecessor  system  apply.  We  multiply  the  Table  58 
event  frequencies  by  the  appropriate  event  performance  time  (see  above) 
to  obtain  the  conflict  workload  weightings  shown  in  Table  68. 

The  R controller  routine  workload  weightings  (Table  66)  and 
surveillance  work  weightings  (Table  57)  used  for  the  predecessor  system 
also  apply  to  sector  conflict  probe  system. 


D.  Area  Navigation  (System  5) 

RNAV  incorporates  navigation  devices  to  achieve  closely  spaced 
arrival  and  departure  and  multi- lane  direct  routes  for  high-density 
airspace. 
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1. 


RNAV  Workload  Model 


RNAV  will  alter  a portion  of  the  event  frequency  data  that 
we  have  included  as  part  of  our  conflict  model.  We  project  no  impact 
on  our  routine  or  surveillance  work  models. 

In  accordance  with  our  analysis  of  Bay  TRACON,  we  assume  RNAV 
will  eliminate  the  occurrence  of  overtaking  conflicts  in  departure 
sectors  as  shown  in  Table  69.  The  Table  69  entries  are  obtained  by  ad- 
justing the  conflict  event  frequency  entries  in  Table  58  which  we  used 
to  model  the  predecessor  sector  conflict  probe  system.  We  assume  RNAV 
will  not  eliminate  or  reduce  conflict  event  occurrences  in  the  arrival 
sectors  nor  will  it  eliminate  or  reduce  crossing  and  merging  conflict 
occurrences  in  the  departure  sectors. 


2.  RNAV  Workload  Weightings 

RNAV  does  not  affect  the  conflict  event  performance  times 
calculated  for  the  predecessor  system.  R controller  conflict  workload 
weighting  may  be  obtained  by  multiplying  these  task  performance  times 
by  the  RNAV  conflict  event  frequencies  in  Table  69.  The  results  will  be 
identical  to  the  workload  weightings  shown  in  Table  68^  except  that  the 
four  entries  shown  for  departure  sector  overtakings  will  each  equal 
zero. 

The  R controller  routine  workload  weightings  (Table  66)  and 
surveillance  workload  weighting  (Table  57)  used  for  the  predecessor  sys- 
tem also  apply  to  the  RNAV  system. 


E . DABS  Data  Link  (System  6) 

The  DABS  data  link  transmits  digital  data  to  pilots,  including 
general  control  instructions  and  collision  avoidance  directives.  The 
data  link  integrated  via  extensive  computerization  is  the  basis  for  such 
control-by-exception  operations.  Here,  the  controller  becomes  a system 
manager  who  is  not  actively  engaged  in  minute-by-minute  tactical 
decision  making,  but  monitors  and  regulates  the  computerized  operation. 


1.  Data  Link  Workload  Model 


The  data  link  based  control-by-exception  operation  will  alter 
many  of  the  sector  team's  communication  and  data  maintenance  activities 
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Table  69 


CONFLICT  EVENT  FREQUENCY  ESTIMATES 
LOS  ANGELES  TRACON,  SYSTEM  5~RNAV 


•k 

Conflict  Event  Frequency  Factor 

r (Confllcts/Hr)  / (Alrcraft/Hr)^l 

Sector 

Visual  Approach  Operations 

Crossing, e^ 

Local 

Merging, e^ 

Overtaking, e^ 

Coordinated 
Approach 
Merging,  e 

AR-1,  Downey  Arrival 

0 

0.5x10“^ 

1.3xl0~^ 

0.8x10"^ 

AR-2,  Stadium  Arrival 

0 

3. 6xl0“^ 

2.3xl0~^ 

0.  8x10“^ 

DR-1,  South  Departure 

0 

0 

0( 1.2xl0~^) 

0 

DR-2,  North  Departure 

3. 8xl0"^ 

0 

0(  2.6x10“^) 

0 

Instrument  Approach  Operations 

Crossing, e^ 

Local 
Merging, e 

Q 

Over taking, e^ 

Coordinated 
Approach 
Merging,  e 

B 

AR-1,  Downey  Arrival 

0 

0.5x10"^ 

2.5x10”^ 

2.4x10“^ 

AR-2,  Stadium  Arrival 

0 

3.6xl0"^ 

4.5x10“^ 

2.4x10"^ 

DR-1,  South  Departure 

0 

0 

0(  1.2x10"^) 

0 

DR-2 , North  Departure 

3.8xl0"^ 

0 

0(  2.6x10"^) 

0 

System  4 event  frequencies  are  Indicated  In  parenthesis. 


168 


that  we  have  included  in  our  routine  and  conflict  work  models.  We  fore- 
see no  impact  on  our  surveillance  work  model.  In  the  following  para- 
graphs we  follow  the  methodology  described  in  the  Bay  TRACON  analysis 
for  adjusting  our  routine  and  conflict  work  models,  under  the  assumption 
that  all  aircraft  are  equipped  with  DABS  data  link. 

Our  interpretations  of  the  tabular  display  effect  upon  the 
composite  team's  routine  task  performance  time  are  summarized  in  Table 
70.  The  corresponding  R controller  routine  task  performance  times  for 
the  four  team  manning  regines  are  shown  in  Tables  71,  72,  73,  and  74. 

The  resulting  R controller  routine  event  performance  times  for  each 
regime  are  summarized  in  Table  75. 

Conflict  resolution  instructions  are  assumed  to  be  transmitted 
by  the  data  link  while  controllers  maintain  cognizance  of  the  computerized 
operation.  The  R controllers  conflict  event  performance  times  (t^,,  t^, 
tp,  and  t^,  respectively)  for  crossing,  local  merging,  overtaking  and 
coordinated  approach  merging  situations  are  each  reduced  to  15  man-sec/ 
conflict. 


2.  Data  Link  Workload  Weightings 

The  R controller  routine  and  conflict  event  frequencies  used 
to  model  the  predecessor  system  apply  to  DABS  data  link  modeling  since 
the  rates  of  occurrence  of  these  events  are  not  affected  by  control-by- 
exception  automation.  We  use  the  appropriate  rourine  event  frequencies 
(Table  49)  and  performance  times  (Table  57)  to  calculate  the  routine 
workload  weighting  summarized  in  Table  76.  The  conflict  event  perfor- 
mance times  (see  above)  and  the  predecessor  RNAV-based  event  frequencies 
(Table  69)  are  used  to  calculate  the  conflict  workload  weightings  shown 
in  Table  77. 

The  R controller  surveillance  workload  weightings  (Table  57) 
used  for  the  predecessor  systems  also  apply  to  the  DABS  data  link  system. 


F.  DABS  Intermittent  Positive  Control 


IPC  provides  traffic  advisors  and  threat  avoidance  commands  to  VFR 
pilots  on  an  as-needed  basis.  Extended  to  IFR  operations  IPC  would 
operate  on  imminent  (e.g.,  lead-time  of  1 to  2 min)  conflict  situations 
that  are  "missed"  by  controllers.  This  is  assumed  to  be  a safety  enhance- 
ment device  that  would  not  effect  the  capacity  considerations  associated 
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Table  70 
COMPOSITE  TEAM 

ROUTINE  TASK  MINIMUM  PERFORMANCE  TIME  ESTIMATES 
LOS  ANGELES  TRACON,  SYSTEM  6— DABS  DATA  LINK 


Routine  Control  Event  Description 


Perfornance  Tine  bv  Task  (nan-sec/event) 


Event 

Function 


raffle 

tructuring 


Basic  Event  and 
Supplemental  Event 


Hasdoff  acceptance 

Manual  acquisition-silent 
Flight  strip  preparation 
Flight  strip  printer  servicing 
Tower  departure  call  (run  down) 
Clearance  delivery 
Controller  coordination 

Handof f initiation-silent 
Controller  coordination 


Initial  pilot  call-in 
TCA  clearance  request 

Initial  controller  response 
Altitude  instruction 
Data  update 

Heading/route  Instruction 
Speed  instruction 
Approach/runvay  advisory 
Data  update 
Traffic  advisory 
ATIS  Advisory 
Altimeter  setting  advisory 
Transponder  code  assignment 
Controller  coordination 

Altitude  instruction 
Data  update 

Controller  coordination 

Heading/route  instruction 
Controller  coordination 

Speed  instruction 

Approach  clearance 
PVD  display  update 

Runway  assignment 

Controller  coordination 

Traffic  advisory 
Pilot  altitude  report 
Pilot  heading/positlon  report 
Pilot  speed  report 
Miscellaneous  A/G  communication 

Frequency  change 

Transponder  code  change 
Approach/runway  advisory 
Altltude/heading/speed  instructlor 


Pilot 

Request 

Altitude  revision 

Controller  coordination 

Route/heading  revision 

Controller  coordination 

Miscellaneous  pilot  request 

General 
Intersector 
Coord  1- 
nation 

Pointout  acceptance 

Polntout  initiation 

Control  instruction  approval 

Planning  advisory 

Aircraft  status  advisory 

General 

System 

Operation 

Data  block  forcing/ removal 

PVD  display  adjustir>ent 

Operational  cognizance 


System  5 performance  times  are  Indicated  In  parenthesis. 
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Routine 

Control  Event  Description 

Event 

Function 

Basic  Event  and 

Supplemental  Event 

Control 

Jurisdiction 

Transfer 

Handoff  acceptance 

Manual  acquisition-silent 

Flight  strip  preparation 

Flight  strip  printer  servicing 
Tower  departure  call  (run  dovm) 
Clearance  delivery 

Controller  coordination 

Handoff  initiation-silent 

Controller  coordination 

Table  71 
R CONTROLLER 

ROUTINE  TASK  MINIMUM  PERFORMANCE  TIME  ESTIMATES 
LOS  ANGELES  TRACON,  SYSTEM  6.  1-MAN  TEAM 


Performance  Time  by  Task  (man-sec /event ) 


A/C 

Commiini' 
cat  ion 


Traffic 

Structuring 

Initial  pilot  call-in 

TCA  clearance  request 

1 

1 

Initial  controller  response 

Altitude  instruction 

Data  update 

Heading/route  instruction 

Speed  Instruction 

Approach/runway  advisory 

Data  update 

Traffic  advisory 

ATIS  Advisory 

Altimeter  setting  advisory 
Transponder  code  assignment 
Controller  coordination 

1 

Altitude  instruction 

Data  update 

Controller  coordination 

Heading/route  instruction 

Controller  coordination 

Speed  Instruction 

Approach  clearance 

PVD  display  update 

Runway  assignment 

Controller  coordination 

Traffic  advisory 

Pilot  altitude  report 

Pilot  heading/position  report 

Pilot  speed  report 

Miscellaneous  A/G  communication 

Frequency  change 

Transponder  code  change 
Approach/runway  advisory 

Altitude /head ing/speed  instruction 

Pilot 

Request 


General 

Intersector 

Coordi- 

nation 


General 
Sy.'.tfTi 
Or-^f  .it  ion 


Altitude  revision 

Controller  coordination 

Route/heading  revision 
Controller  coordination 

Miscellaneous  pilot  request 


Point out  acceptance 
Pointouc  initiation 
Control  Instruction  approval 
Planning  advisory 
Aircraft  status  advisory 


Data  block  forcinji/rcroval 
i’VO  display  adjustment 


"Operational  cognizance 


I 


Table  72 
R CONTROLLER 

ROUTINE  TASK  MINIMUM  PERFORMANCE  TIME  ESTIMATES 
LOS  ANGELES  TRACON,  SYSTEM  6,  1.5-MAN  TEAM 


Routine  Control  Event  Description 


Performance  Time  by  Task  (man-sec/event) 


Event 

Function 


A/G 

Coninuni 

cation 


General 

Intersector 

Coordi- 

nation 


I r.eneral 
I System 
Opera t Ion 


Basic  Event  and 
Supplemental  Event 


Handoff  acceptance 

Manual  acquisition-silent 
Flight  strip  preparation 
Flight  strip  printer  servicing 
Tower  departure  call  (run  down) 
Clearance  delivery 
Controller  coordination 

Handoff  initiation-silent 
Controller  coordination 


Initial  pilot  call-in 
TCA  clearance  request 

Initial  controller  response 
Altitude  Instruction 
Data  update 

Heading/route  instruction 
Speed  instruction 
Approach/runway  advisory 
Data  update 
Traffic  advisory 
AXIS  Advisory 
Altimeter  setting  advisory 
Transponder  code  assignment 
Controller  coordination 

Altitude  instruction 
Data  update 

Controller  coordination 

Ueading/route  Instruction 
Controller  coordination 

Speed  instruction 

Approach  clearance 
PVD  display  update 

Runway  assignment 

Controller  coordination 

Traffic  advisory 
Pilot  altitude  report 
Pilot  heading/position  report 
Pilot  speed  report 
Miscellaneous  A/G  communication 

Frequency  change 

Transponder  code  change 
Approach/runway  advisory 
Altlcud e/heading/speed  instruct lo 


Altitude  revision 

Controller  coordination 

Route/heading  revision 
Controller  coordination 

Miscellaneous  pilot  request 


Polntout  acceptance 
Pointout  initiation 
Control  instruction  approval 
Planning  advisory 
Aircraft  status  advisory 


Data  block  forcing/ removal 
rVD  display  adjustment 


‘Operational  cognizance 
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Table  73 
R CONTROLLER 

ROUTINE  TASK  MINIMUM  PERFORMANCE  TIME  ESTIMATES 
LOS  /VNGELES  TRACON,  SYSTEM  6,  2 -MAN  TEAM 


Routine  Control  Event  D-^stription 


Perfocnunce  Ti.-ne  by  Task  (nan-sec/evcnt) 


raffle  Initial  pilot  call-in 

tructuring  TCA  clearance  request 

Initial  controller  response 
Altitude  instruction 
Data  update 

Heading/ route  instruction 
Speed  instruction 
Approach/runway  advisory 
Data  update 
Traffic  advisory 
ATIS  Advisory 
Altimeter  setting  advisory 
Transponder  code  assignment 
Controller  coordination 

Altitude  Instruction 
Data  update 

Controller  coordination 

Heading/route  instruction 
Controller  coordination 

Speed  instruction 

Approach  clearance 
FVD  display  update 

Runway  assignment 

Controller  coordlnatl'^n 

Traffic  advisory 
Pilot  altitude  report 
Pilot  heading/position  report 
Pilot  speed  report 
Miscellaneous  A/G  communication 

Frequency  change 

Transponder  code  change 
Approach/runway  advisory 
Altitude/heading/speed  Inst rue tioi 


Event  Basic  Event  and 

Function  Supplemental  Event 

^'ntrol  Handoff  acceptance 

Jurisdiction  Manual  acquisition-silent 

iiansfer  Flight  strip  preparation 

Flight  strip  printer  servicing 
Tower  departure  call  (run  dovni) 
Clearance  delivery 
Controller  coordination 

Handoff  initiation-silent 
Controller  coordination 


Altitude  revision 

Controller  coordination 

Route/heading  revision 
Controller  coordination 

Miscellaneous  pilot  request 


Point out  acceptance 
Point out  initiation 
Control  instruction  approval 
Planning  advisory 
Aircraft  status  advisory 


General  Data  block  forclng/reroval 

>ysten  display  adjustrev.t 

Oporai  ion 


A/G 

Communi- 

cation 


Inter-  F.irc-to- 
phone  Face 
Corjnun  i - Commu  n i - 
cation  cation 


General 
Intersector 
Coord i- 
naC ion 


♦Operational  cognizance 


Table  74 

ROUTINE  TASK  MIN?>l5S’*?IRl!'ilSANCE  TIME  ESTIMATES 
LOS  ANGELES  TRACON.  SYSTEM  ft.  2 . 5-MAN  TEAM 


Routine  C.'ntrol  Event  Ji-'scription 


PerfocnanL-c  Tine  by  Task  (nan-sec/evont ) 


Event  Basic  Event  and 
Function  Supplemental  Event 


Handoff  acceptance 

Manual  acquisition-silent 
Flight  strip  preparation 
Flight  strip  printer  servicing 
Tover  departure  call  (run  down) 
Clearance  delivery 
Controller  coordination 

Handoif  initiation-silent 
Controller  coordination 


raffic  Initial  pilot  call-in 

tructuring  TCA  clearance  request 

Initial  controller  response 
Altitude  instruction 
Data  update 

Heading/route.  instruction 
Spaed  instruction 
Approach/runway  advisory 
Data  update 
Traffic  advisory 
AXIS  Advisory 
Altimeter  setting  advisory 
Transponder  code  assignment 
Controller  coordination 

Altitude  instruction 
Data  update 

Controller  coordination 

Heading/route  instruction 
Controller  coordination 

Speed  instruction 

Approach  clearance 
FVD  display  update 

Runway  assignment 

Controller  coordlnati'^n 

Traffic  advisory 
Pilot  altitude  report 
Pilot  heading/position  report 
Pilot  speed  report 
Miscellaneous  A/G  cocsuiiicatlon 

Frequency  cubage 

Transponder  code  change 
Approach/runway  advisory 
Altitude/heading/speed  instrucCior 


Pilot  Altitude  revision 

Request  Controller  coordination 

Route/heading  revision 
Controller  coordination 

Miscellaneous  pilot  request 


A/G 

Comnun  i- 
cat ioa 


General  Pointout  acceptance 

Interse.'tor  ^ . , . . . 

Coordi-  Pointout  initiation 

nation  Contrcl  instruction  approval 


General 

System 

Cporatlon 


Planning  advisory 
Aircraft  status  advisory 


Data  block  forcing/reroval 
VVn  display  adjustment 


♦Operational  cognizance 
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Table  75 
R CONTROLLER 

ROUTINE  EVENT  MINIMUM  PERFORMANCE  TIME  ESTIMATES 
LOS  ANGELES  TRACON.  SYSTEM  6— DABS  DATA  LINK 


Control  Event  Dt-scription 


Ev<int  3asic  Event  and 

Korction  Suppleiiiental  Event 

Har.doff  acceptance 

Manual  acquisition-silent 
Flight  strip  preparation 
Flight  strip  printer  servicing 
Tower  departure  call  (run  down) 
Clearance  delivery  coordination 
Controller  coordination 

Handoff  initiation-silent 
Controller  coordination 


raffic  Initial  pilot  call-in 

tructuring  TCA  clearance  request 

Initial  controller  response 
Alti*-ude  instruction 
Data  update 

Heading/ route  instruction 
Speed  instruction 
Approach/runway  advisory 
Data  update 
Traffic  advisory 
ATIS  Advisory 
AltiTQeter  setting  advisory 
Transponder  code  assignment 
Controller  coordination 

Altitude  instruction 
Data  update 

Controller  coordination 

Headiag/route  instruction 
Controller  coordination 

Speed  instruction 

Approach  clearance 
PVD  display  update 

Runway  assignment 

Controller  coordination 

Traffic  advisory 
Pilot  altitude  report 
Pilot  heading/position  report 
Pilot  speed  report 
Miscellaneous  A/G  communication 

Frequency  change 

Transponder  code  change 
Approach/runway  advisory 
Altltude/heading/speed  in struct lor 


Altitude  revision 

Controller  coordination 

Route/headlng  revision 
Controller  coordination 

Miscellaneous  pilot  request 


Pointout  acceptance 
Polntout  initiation 
Control  instruction  approval 
Planning  advisory 
Aircraft  status  advisory 


C«'i'eral  Data  block  rorcing/rer.ovnl 

rVl)  tli:,play  r.H justiicnt 


Perfornance  Time  by  Team  (•^an-sec/eveni ) 


1 . 0-Man 
Team 


1 . 5-Man 
Tear?. 


2 . 0-Man 
Team 


* Indicated  event  occurs  at  half  the  frequency  rate  shown  in  Table  49. 


Table  76 


R CONTROLLER  ROUTINE  WORKLOAD  WEIGHTINGS 
LOS  ANGELES  TRACON,  SYSTEM  6— DABS  DATA  LINK 


Sector 

R Controller  Routine  Workload  Weighting, 
k, , by  Team  (man-sec/alrcraf t) 

X 

1-Man 

Team 

1.5-Man 

Team 

2-Man 

Team 

2 . 5-Man 
Team 

AR-l,  Downey  Arrival 

48 

45 

41 

41 

AR-2,  Stadium  Arrival 

64 

60 

57 

57 

DR-1,  South  Departure 

45 

42 

38 

38 

DR-2,  North  Departure 



44 

42 

38 

38 

with  normal  sector  task  activities.  As  in  the  case  of  the  Bay  TRACON 
analysis,  we  do  not  further  evaluate  IPC;  it  is  considered  to  be  an 
incremental  add-on  to  the  data  link  system  but  with  no  independent 
effect  upon  workload. 
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Indicated  crossing,  local  merging,  and  overtaking  conflict  workload  weightings  are  for  any  of  the 
1.5-man,  2-man,  and  2.5-man  sector  team-manning  regimes. 


XII  LOS  ANGELES  TRACON  SECTOR  CAPACITY  AND  MANNING 


In  this  section,  we  estimate  traffic  capacities  at  the  four  Los 
Angeles  TRACON  sectors  for  each  sector  team  manning  regime  under  each  of 
the  six  ATC  system  alternatives.  We  use  these  capacities  to  estimate 
multi-sector  minimum  manning  requirements  for  a range  of  traffic  levels; 
these  estimates  enable  comparisons  of  the  impact  of  the  various  UG3RD 
systems  on  facility  operations. 


A.  Sector  Capacity 

We  use  the  routine,  surveillance,  and  conflict  workload  weightings 
established  for  the  Los  Angeles  TRACON  and  follow  the  procedure  pre- 
viously described  for  the  Bay  TRACON  analysis  to  estimate  sector  capac- 
ities. These  estimated  sector  capacities  for  both  visual  and  instrument 
approach  operations  are  presented  in  Tables  78,  79,  80,  and  81,  re- 
spectively, for  each  of  the  four  sectors. 

These  sector  capacities  directly  reflect  the  R controller  activity 
requirements  defined  by  the  workload  weightings.  We  see  that  feeder 
and  final  sector  capacities  for  instrument  approach  operations  are 
slightly  less  than  those  for  visual  operations  because  of  the  additional 
approach  merging  work,  while  departure  sector  capacities  are  not  af- 
fected by  approach  conditions.  The  sector  capacities  generally  Increase 
for  each  successive  increment  in  sector  team  manning  because  the  R con- 
troller usually  offloads  some  portion  of  routine  or  conflict  work  to 
the  added  team  members.  In  some  situations,  the  amount  of  work  offloaded 
does  not  sufficiently  increase  sector  capacity;  in  the  case  of  2-man 
versus  2.5-man  team  regimes  for  the  DABS  data  link  system,  no  work  off- 
loading is  projected  and  sector  capacities  are  identical  for  the  two 
regimes.  Therefore,  the  2-man  team  is  the  practical  manning  limit  under 
System  6 operations. 

Each  UG3RD  ATC  system  successor  to  the  ARTS  III  Base  System  in- 
cludes an  automation  feature  that  is  added  onto  the  operational  features 
of  its  predecessor.  Since  each  UG3RD  automation  feature  further  reduces 
R controller  workload  requirements  to  varying  extents,  sector  capacity 
generally  increases  as  each  successive  system  evolves.  However,  some 
of  the  automation  features  do  not  alleviate  workload  in  certain  opera- 
tional environments.  For  example,  basic  metering  and  spacing  supports 
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approach  operations,  but  is  not  shown  to  increase  departure  sector 
capacity.  Similarly,  RNAV  is  not  assumed  to  be  effective  in  reducing 
work  requirements  for  arrival  operations,  and  is  not  shown  to  increase 
arrival  sector  capacity. 

We  note  that  our  workload  analyses  assume  100  percent  deployment  of 
RNAV  and  DABS  data  link  airborne  equipment  for  the  aircraft  fleet  under 
TRACON  control.  We  do  not  explicitly  assess  the  effect  on  capacity  of 
partial  deplo3raient  of  avionics  equipment.  However,  based  on  our  previous 
analyses  of  enroute  ATC  aircraft  equipment  deployments,  first-cut  capac- 
ity estimates  for  partial  deployment  may  be  made  by  linear  interpolations 
in  Tables  78,  79,  80,  and  81,  as  was  explained  under  the  Bay  TRACON 
analysis. 


B.  Multi-Sector  Manning 

Subject  to  the  traffic  handling  constraints  imposed  by  our  sector 
capacity  calculations,  we  wish  to  compare  the  relative  manning  require- 
ments of  each  of  the  six  alternative  ATC  systems  associated  with  the 
joint  operation  of  the  four  sectors. 

We  use  sector  capacities  calculated  for  instrument  approach  con- 
ditions rather  than  visual  because  instrument  conditions  are  more  criti- 
cal constraints  to  controller  traffic  handling  capabilities. 


1.  Manning  Calculations 

Again  using  the  previously  described  Bay  TRACON  analysis  pro- 
cedure, we  calculate  for  each  system  the  minimum  number  of  manned  con- 
trol positions  required  to  process  various  levels  of  traffic  through 
each  sector,  without  exceeding  our  R controller  workload-based  capacity 
constraints.  The  calculation  worksheets  including  the  manning  estimates 
are  shown  in  Tables  82,  83,  84,  85,  86,  and  87,  respectively,  for  the 
six  alternative  ATC  systems.  The  traffic  base  is  the  1975  statistics 
reported  for  the  8-hour  day  shift  for  the  Los  Angeles  TRACON  busy  day 
(90th  percentile) 

Controller  manning  requirements  are  made  for  25  percent  incre- 
ments in  day-shift,  peak-hour  traffic  projections.  Manning  estimates 
for  each  of  the  four  sectors  are  made  by  comparing  each  traffic  increment 
against  the  sector  teams'  growth  potentials,  and  identifying  the  team 
needed  to  handle  the  projected  traffic.  Allowances  are  made  for  sharing 
a coordinator  between  two  arrival  or  two  departure  sectors,  even  though 
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*Source:  "Application  of  ATC  Terminal  Standard  for  PY  1975,  computer  printout  manuscript.  Air  Traffic  Service, 

tTrafflc  growth  potential  • capacity/1975  traffic 

4^Coordin8tor  (1/2'man)  required  for  companion  sector 

<'•  rorformance  monitoring  function  only  assumed 

^•‘Kliinl  sector  runctlon  assumed 


DAY-SHIFT,  PEAK-HOUR  MANNING  CALCULATIONS 
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DAY-SHIFT,  PEAK-HOUR  MANNING  CALCULATIONS 
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Table  86 
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iVrformancc  monitoring  function  only  assumed 
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(irorformance  monitoring  function  only  assumed 
*<*f'hi.il  sector  function  assumed 


only  one  of  the  sectors  may  actually  need  the  coordinator  (i.e.,  to 
match  team  capacity  with  the  traffic  projection). 

In  regard  to  arrival  operations^  we  assume  that  some  special 
manning  expansions  may  be  applied  to  handle  traffic  growth  beyond  the 
traffic  level  at  which  both  the  arrival  sectors  reach  their  team  manning 
limit  (i.e.,  2-men  for  DABS  data  link,  and  2.5-man  for  the  other  systems). 
For  our  purpose,  we  assume  that  each  parallel  monitor  position  will  be 
expanded  (possibly  by  being  transformed  into  the  equivalent  of  two  final 
sectors),  and  we  add  one  controller  to  each.  For  example,  under  ARTS 
III  operations  in  Table  82,  we  assume  four  controllers  will  replace  the 
two  parallel  monitors  at  the  1.5  traffic  factor  in  order  to  alleviate 
the  workload  of  the  two  arrival  sectors. 

We  next  estimate  the  flight  data  position  manning  requirements 
needed  to  operate  the  flight  progress  strip  printers.  No  flight  data 
positions  were  manned  during  our  observations  at  Los  Angeles  TRACON; 
two  flight  strip  pointers  are  serviced  by  the  two  departure  sector  teams, 
and  computer  printed  strips  are  not  delivered  to  the  arrival  sectors. 

As  in  our  Bay  TRACON  analysis,  we  assume  that  under  the  ARTS  III  Base 
System,  manning  of  two  flight  data  positions  (to  distribute  arrival  and 
departure  flight  strips)  could  be  delayed  at  most  until  traffic  activity 
doubles,  as  shown  in  Table  82.  Also  in  Table  82,  we  assume  that  one  of 
these  positions  would  be  manned  earlier  to  support  arrival  operations 
when  these  sector  teams  reach  their  manning  levels.  However,  the  auto- 
mated data  handling  system  is  assumed  to  eliminate  flight  strip  printers 
and  attendant  manning,  and  flight  data  position  manning  equals  zero  in 
Tables  83  through  87  for  all  the  alternative  UG3RD  systems. 

The  total  multi-sector  day-shift  minimum  manning  requirements 
are  calculated  by  summing  the  sector  team,  parallel  monitor  and  flight 
data  manning  for  each  traffic  factor.  (The  manning  estimates  do  not 
include  staffing  allowances^®  for  administration,  relief,  annual  and 
sick  leave,  excess  shift  capacity,  training,  and  special  assignments.) 

We  estimate  that  a total  of  seven  manned  positions  correspond  to  the 
1975  day-shift  traffic  (1.0  traffic  factor)  for  the  ARTS  111  base  system, 
as  shown  in  Table  82.  This  1975  manning  level  defines  the  base  manning 
factor  (1.0  in  Table  82),  and  is  used  as  the  reference  for  calculating 
manning  factors  for  each  traffic-factor  increment  under  each  alternative 
ATC  system.  That  is,  the  manning  factor  data  shown  in  Tables  82  through 
87  relate  each  projected  manning  requirement  to  that  calculated  for  the 
1975  ARTS  III  base  system. 
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2.  Manning  Comparisons 

Our  manning  factor  calculations  corresponding  to  selected 
traffic  factors  are  summarized  by  ATC  system  in  Table  88.  The  manning 
factor  estimates  represent  adjustments  to  sector,  parallel  monitor,  and 
flight  data  positions  needed  to  handle  increases  in  1975  traffic  activity. 
Consultation  with  Los  Angeles  TRACON  personnel  showed  that  they  en- 
visioned no  further  reconfiguration  beyond  the  current  four-sector/two- 
parallel  feeders  design.  Therefore,  the  expansion  of  the  parallel  moni- 
tor manning  assumed  in  this  analyses  is  based  on  our  judgment  regarding 
the  need  for  position  additions  if  significant  traffic  growth  were  to 
occur. 


This  manning  estimation  procedure  as  applied  to  Los  Angeles 
TRACON  does  not  account  for  the  possible  traffic  constraining' delays  in- 
duced by  terminal  airspace  capacity  limitations.  Based  on  our  consul- 
tations with  the  TRACON  personnel,  field  observations,  and  operations 
analyses,  we  conclude  that  whatever  critical  delay-producing  bottleneck 
situations  may  exist  are  related  to  LAX  airport  constraints  rather  than 
terminal  airspace  constraints. 

In  regard  to  delay-related  implications  of  future  operations, 
the  manning  requirements  in  Table  88  are  shown  generally  to  increase  as 
traffic  approaches  twice  the  1975  level  and  to  gradually  level  off  as 
traffic  increases  beyond  the  2.0  factor  (or  thereafter,  depending  on  the 
alternative  UG3RD  system).  The  leveling-off  is  due  to  the  inability  of 
adding  controllers  to  those  sector  teams  operating  at  their  maximum 
manning  level.  Therefore,  certain  sectors  are  workload  saturated  and 
cannot  handle  additional  traffic.  In  fact,  delays  may  be  induced  earlier 
by  the  arrival  sectors,  which  reach  maximum  manning  before  the  traffic 
projection  doubles.  However,  delays  generated  by  terminal  airspace 
should  not  be  significant  because  traffic  at  LAX  is  forecast  to  increase 
only  by  30  percent  (relative  to  1975)  by  the  year  2000.* 

Since  major  workload  saturation  situations  would  occur  if  traf- 
fic increases  significantly  beyond  the  2.0  factor,  such  traffic  disrup- 
tions would  cause  significant  change  to  the  operational  assumptions  we 
have  made  in  modeling  sector  capacity  and  manning.  Therefore,  as  far  as 
the  manning  factor  estimates  in  Table  88  are  concerned,  we  suggest  that 
comparisons  using  these  data  be  made  between  systems  only  for  those  traf- 
fic factors  at  or  below  2.0.  Comparisons  at  the  higher  traffic  levels 


"k 

Airport  traffic  activity  forecast  provided  by  FAA  (AVP),  October  1975. 
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would  have  no  realistic  meaning^  particularly  since  Los  Angeles  TRACON 
is  not  expected  to  operate  at  these  levels.  In  the  following  paragraph, 
we  do  examine  manning  requirements  at  the  1.0  and  2.0  traffic  factors 
for  sake  of  comparing  the  potential  operational  impacts  of  the  alterna- 
tive ATC  systems. 

In  Table  88,  the  ARTS  III  base  system  is  shown  to  be  capable 
of  handling  a doubling  of  1975  traffic  if  manning  is  more  than  doubled 
(i.e.,  increased  by  129  percent  relative  to  1975  manning).  Significant 
reductions  in  these  manning  requirements  are  associated  with  the  auto- 
mated data  handling  and  DABS  data  link  operations.  Automated  data 
handling  reduces  manning  (relative  to  ARTS  III)  by  14  percent  for  the 
1.0  traffic  factor,  and  by  37  percent  for  the  2.0  traffic  factor.  DABS 
data  link  reduces  manning  (relative  to  ARTS  III)  by  43  percent  and  115 
percent,  respectively,  for  the  1.0  and  2.0  traffic  factors.  This  shows 
that  the  fully  upgraded  system  is  capable  of  handling  twice  the  1975 
traffic  with  only  a 14  percent  increase  in  the  current  manning  complement. 
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Appendix 
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POTENTIAL  CONFLICT  MODELS 
AND  APPLICATIONS 


This  appendix  describes  mathematical  models  for  estimating  the 
expected  frequency  of  potential  conflicts  and  their  applications  to  the 
eleven  selected  sectors  of  the  Bay  TRACON.  This  examination  of  sector 
potential  conflict  situations  was  performed  using  techniques  based  on 
the  RECEP  methodology  developed  during  previous  SRI  research,  and  adapted 
to  the  Bay  TRACON  operations  in  accordance  with  our  on-site  observations, 
data  collection  and  controller  interviews. 


A.  Potential  Conflict  Frequency  Models 

Potential  conflicts  are  projected  violations  of  separation  minlmums 
perceived  by  controllers.  Since  this  project  was  concerned  with  radar 
environment,  the  ATC  radar  separation  minlmums  are  the  criteria  to  be 
maintained.  These  criteria,  based  on  our  observations  of  the  actual 
separations  exercised  by  controllers,  are: 

• Aircraft  are  separated  by  at  least  1,000  feet  in  altitude. 

• Aircraft  on  departure  routes  about  to  enter  ARTCC  airspace 
are  separated  by  at  least  five  nautical  miles. 

• All  other  aircraft  are  separated  by  three  to  six  nautical 
miles,  depending  on  the  sizes  and  vortex  generating 
capabilities  of  the  aircraft  involved. 

The  three  primary  means  by  which  these  separation  minlmums  can  be 
violated  are  by  (1)  the  intersection  of  two  aircraft  flight  paths, 

(2)  one  aircraft  overtaking  another,  or  (3)  the  merging  of  two  or  more 
flight  paths  into  one.  The  possible  events  resulting  from  these  viola- 
tions are  listed  in  Table  A-1.  Since  there  are  differences  in  the  dif- 
ficulty of  resolving  the  potential  conflicts  resulting  from  these  events, 
the  events  should  also  be  classified  by  type  of  aircraft  involved,  such 
as  nonmilitary  versus  nonmilitary,  military  versus  nonmilitary,  and 
military  versus  military.  However,  during  this  project,  there  were  not 
sufficient  data  to  make  these  distinctions  meaningful. 
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Table  A-1 


EVENTS  RESULTING  IN  VIOLATION 
OF  RADAR  SEPARATION  MINIMA 


Crossing 

Intersection  of  two  aircraft  flight  paths 

conflicts 

at  the  same  altitude. 

Intersection  of  a transitioning  (climbing 
or  descending)  aircraft  with  a level  air- 
craft at  altitude. 

Intersection  of  two  transitioning  aircraft. 

Overtake 

Aircraft  at  the  same  latitude. 

conflicts 

Aircraft  transitioning  on  the  same  track. 

Aircraft  on  separate  but  merging  tracks 
where  the  merge  sequence  has  been  set  up 
at  an  upstream  area,  requiring  "holes"  to 
be  maintained  in  each  feeder  traffic  stream. 

Merging 

The  aggregation  of  two  or  more  "feeder" 

conflicts 

flight  paths  at  the  same  point  in  space. 

SRI  has  developed  a number  of  simple  mathematical  models  for  pre- 
dicting the  expected  number  of  such  conflict  events.  Data  acquired  in 
our  hour-long  measurement  phases  were  used  to  estimate  the  expected 
frequencies  of  conflict  events  for  the  air  routes  comprising  each  in- 
vestigated sector.  The  actual  development  of  the  models  used  to  predict 
the  expected  number  of  conflicts  within  and  between  air  routes  is  de- 
scribed in  Reference  13.  Only  the  resulting  expressions  are  presented 
here. 


1 . Crossing  Conflict  Events 

The  frequency  of  conflict  events  at  an  air  route  intersection 
depends  on  the  aircraft  flow  rate  and  velocity  along  each  route,  the 
minimum  separation  requirements,  the  angle  of  Intersection  between  the 
routes,  and  the  number  of  flight  levels  at  which  conflicts  would  poten- 
tially occur.  The  average  frequency  of  conflicts  at  an  Intersection  can 
be  found  from: 

196 


c 

X 


''ll"l2“  \/''ll  ''L  - 

V. , V. „ sin  a 
il  i2 


where 


C = average  number  of  crossing  conflicts  per  hour 
at  intersection  x 

n^j^  = flow  of  aircraft  at  flight  level  i along  route  1 
(aircraft  per  hour) 

n^2  = flow  of  aircraft  at  flight  level  i along  route  2 

(aircraft  per  hour) 

s = separation  minimum  used  by  controllers  (nautical 
miles) 

v^j^  = average  speed  of  aircraft  at  flight  level  i along 
route  1 

v^2  = average  speed  of  aircraft  at  flight  level  i along 

route  2 

a = angle  of  intersection  between  the  routes 

E = indicates  the  summation  over  all  flight  levels  at 
which  conflicts  may  occur. 


Intersections  of  more  than  two  air  routes  were  treated  by 
finding  the  sum  of  the  expected  number  of  conflicts  between  all  possible 
pairs  of  air  routes.  The  expected  number  of  conflicts  were  calculated 

for  each  flight  level  considered,  and  summed  over  all  flight  levels  to 

determine  the  total  conflict  frequency  associated  with  that  interaction. 

When  one  of  the  crossing  routes  is  a transition  route,  it  is 

necessary  to  evaluate  the  additional  effects  due  to  the  interaction  of 

the  transitioning  aircraft  with  air  traffic  at  more  than  one  flight 
level  on  the  other  route.  A transitioning  aircraft  can  conflict  not 
only  with  air  traffic  at  the  actual  route  crossing  altitude,  but  also, 
because  of  separation  standards,  it  can  conflict  with  traffic  above  and 
below  this  flight  level.  For  this  reason  the  air  traffic  controller 
usually  provides  separation  as  if  transitioning  aircraft  "block"  more 
than  one  altitude  at  the  same  time.  This  concept  is  equivalent  to  treat- 
ing a transition  crossing  as  a number  of  simultaneous  level-to-level 
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crossings  at  the  "blocked"  altitudes.  Therefore,  calculating  the  ex- 
pected number  of  such  conflicts  entails  summing  the  expected  number  of 
crossing  conflicts  at  each  flight  level  affected  by  the  transitioning 
route.  The  number  of  altitudes  that  are  affected  is  a function  of 
climb/descent  angle  and  separation  criteria.  Procedures  developed^  can 
be  used  to  determine  the  vertical  distance  required  (and  therefore  the 
number  of  flight  levels  affected)  by  a transitioning  aircraft  flow  while 
crossing  an  air  route.  Knowing  this  value  and  the  vertical  separation 
minimum,  it  is  possible  to  determine  which  flight  levels  are  affected  by 
this  event.  The  number  of  potential  conflicts  resulting  between  the 
aircraft  flow  on  each  of  these  flight  levels  and  the  flow  on  the  tran- 
sitioning route  can  then  be  determined  and  summed. 


2.  Merging  Conflict  Events 

The  frequency  of  conflict  events  at  each  flight  level  of  an 
air  route  merge  point  is  assumed  to  be  one-half  that  of  a full  air  route 
intersection  with  similar  flow  rates,  velocities,  separation  requirements, 
and  angles  of  intersection.  Potential  violations  of  separation  minimums 
downstream  from  the  common  merge  point  are  treated  as  overtaking  con- 
flicts since  the  interacting  aircraft  traffic  streams  are  in  trail,  or 
overlapping  in  this  area.  The  average  frequency  of  merging  conflicts 
per  hour,  at  merge  point,  y,  is  simply 
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where  Equation  (2)  parameters  are  the  same  as  defined  for  Equation  (1). 


3.  Overtake  Conflict  Events 


The  expected  frequency  of  overtakes  along  a level  or  tran- 
sitioning route  and  between  level  and  transitioning  routes  in  the  same 
direction  can  be  determined  from  the  following  relationship 
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where 
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m = 
I = 
n.  = 
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average  number  of  overtakes  per  hour  along  route  z 
number  of  discrete  speed  categories  along  the  route 
length  of  air  route  (nautical  miles) 


flow  rate  of  aircraft  travelling  at  the  i 
(aircraft  per  hour) 

th 


th 


speed 


= average  speed  of  the  i speed  class  (knots) 


flow  rate  of  aircraft  travelling  at  the  k 
(aircraft  per  hour) 

th 


th 


speed 


Vj^  = average  speed  of  the  k speed  class  (knots) 

s = separation  minimum  used  by  controllers 
(nautical  miles) 

I V.  - Vj^l  = magnitude  of  the  difference  in  velocities  of 
the  two  speed  categories. 


In  this  relationship^  the  summation  symbol  (E)  indicates  that 
the  calculation  is  performed  for  each  possible  pair  of  speed  categories 
and  these  results  are  then  summed  to  find  the  total  number  of  potential 
overtakes.  This  procedure  is  followed  for  each  flight  level  on  a level 
route  and  for  each  transition  route  in  a sector. 


B.  Sector  Conflict  Frequency  Factors 

Equations  (1),  (2),  and  (3)  estimate  the  expected  number  of  poten- 
tial conflict  occurrences  at  a single  confliction  point  or  route  for  a 
given  rate  of  flow  within  each  route.  These  relationships  may  be  used 
to  calibrate  a generalized  conflict  occurrence  model  in  which  sector 
conflict  event  frequencies  are  related  to  overall  sector  traffic 

2 

Number  of  crossing  conflicts /hour  = e N 

a 

2 

Number  of  local  merging  conflicts /hour  = e N 

n 

Number  of  overtaking  conflicts /hour  = 

2 

Number  of  coordinated  approach  merging  conflicts/hour  = e N 

& 
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where: 


N is  the  number  of  aircraft/hr  through  the  sector 

®c’®m^®o  ®a  i^sspectively  are  frequency  factors  that 
measure  the  rates  of  occurrence  of  crossing,  local 
merging,  overtaking,  and  coordinated  approach  merging 
conflicts  for  the  sector  measured  in  (conflicts/hr)/ 
(aircraft/hr)2 


The  frequency  factors,  e^,  e^,  and  e^  are  calculated  (as  de-  j 

scribed  below)  using  Equations  (1),  (2),  and  (3)  for  a single  set  of 
traffic  route  flow,  route  distribution  and  speed  class  data  for  a sector. 

This  data  set  describes  the  mutually  occurring  conflict  events  associated 
with  one  specific  hourly  traffic  flow  rate  through  the  sectors.  The 
conflict  occurrence  results  are  summed  over  all  conflict  points  and 
routes  to  obtain  the  expected  number  of  potential  crossing  local 

merging  (Ejj,),  overtaking  (Eq),  and  coordinated  approach  merging  (E^) 

conflicts/hr  for  the  entire  sector:  I 


E = E C for  all  intersection  points  x = 1,2,... 

C XX 

E = E M for  all  local  merge  points  y = 1,2,... 
myy  ^ -r 

E = E 0 for  all  routes  z = 1,2,... 
o z 2 

E^  = E M for  all  approach  merge  points  y = 1,2,... 


Recall  that  My  and  O2  are  calculated  as  functions  of  pairwise 
products  or  bilinear  functions  of  traffic  flow  rates  on  individual 
routes  through  the  sector.  The  corresponding  sector  traffic  flow  rate, 
n,  measured  in  aircraft /hr.  is: 


n = E n for  all  routes  z = 1,2,... 
z z 


The  frequency  factors  as  a function  of  sector  traffic  are  calculated 
as  follows: 
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Assuming  the  traffic  along  each  route  will  vary  in  direct  propor- 
tion to  the  traffic  distribution  used  in  our  calibrations  (and  that 
other  parameters  also  remain  fixed),  the  products  e^N^,  and 

e^N^  estimate  the  number  of  conflicts  per  hour  corresponding  to  any 
value  of  N aircraft/hour  through  the  sector.  We  need  not  calculate  in- 
dividual values  of  Cj^,  and  for  each  intersection,  merge  and  route 
for  each  value  of  N. 


« 
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